Why do classes in javax.mail store system properties in static fields? [closed]

Question

I've ran into a problem handling file names in javax.mail and some of those aspects need to be configured by session properties and some by system properties. Many classes of javax.mail seem to store the properties they work on in static fields, like in the following example for MimeBodyPart:

private static final boolean encodeFileName =
PropUtil.getBooleanSystemProperty("mail.mime.encodefilename", false);

From my understanding, this binds the concrete value of the system property to the life of the class in some concrete classloader. Whoever loads that class first, is the only one being able to influence the value. That was exactly what happened to me:

I knew that I needed to set some particular system property to influence file name handling and did so where I handled the file name, to keep things as close together as possible for documentation purposes etc. But for some reason, former code loaded the class of interest earlier, binding the wrong value to the static field. The only way to change this was to move setting my value to an earlier place in the call hierarchy, but it took me some time until I noticed the static-field thing.

That looks like a bad strategy to me, because I can't easily know which code with which I share the same classloader uses the same classes I do. In theory this would force me to set my system properties when starting the JVM already, making an implementation detail of my code an admin-detail in various different circumstances. If system properties are used at all instead of session-once, I would have expected those are queried live as well like session-once. Otherwise it's unnecessary difficult to change the corresponding settings under certain circumstances and use cases.

OTOH, the current approach might simply have some benefits I'm not aware of, like querying system properties is expensive as hell or alike.

So, what are the good reasons to do what MimeBodyPart does above?

Answer 1

You're right, @maio290, it was purposely designed poorly. :-)

In a mutli-threaded application, querying the property dynamically doesn't really help.

In most cases these static properties were not expected to change over the lifetime of an application.

In some cases, the use of static was an unfortunate compromise because the code that needed it didn't have access to the Session. Changing all the APIs to pass the Session through explicitly would've made the code more complex.

Thread local storage was considered, but that depends too heavily on the threading model used by the application.

Wherever possible, Session properties were used, but in some cases there was no good way to do that so System properties were used.