monline

I'm sure thousands have stumbled on this before me, but still, it's weird and I cannot explain why it works as it works. At first glance it appeared that if you define a variable in a public class as public static final (ie. a constant) and the variable has a primitive type, then other classes referencing this variable will somehow "cache" the variable value in their own .class file. Looking deeper into the problem I've discovered that the situation is not as bad as I feared: I just crossed javac compiler's string concatenation optimization and it seems it does a bit "too much" for my taste.
Update: Jeff provided a reference to sections of the Java Language Specification that explain why and how this is working. The relevant term is: compile-time constants.

Let's see an example.
Create the file Alice.java as:

Create the file Bob.java as:

Now compile them and run Bob by executing the following commands:

The output will be the values of Alice's static variables:

Now change the value of both variables in Alice.java to something else.
Eg.

Compile it (just Alice.java!) and run Bob again:

The value of var1 did not change, but the value of var2 did!
This is not some stupid mistake (at least it's not mine ). The two invocations of Bob's main() method occured in different JVM processes ... ie. totally independently from each other.

Now get a hexeditor and take a look on the bytecode of the Bob.class file. You will find that it contains the value of Alice.MY_STATIC_FIELD1 "burnt" into the bytecode. Actually what happens is that when the compiler evaluates the System.out.println("var1: " + Alice.MY_STATIC_FIELD1); line in Bob.java, it takes the value of Alice.MY_STATIC_FIELD1 and appends it to the "var1: " string and stores the concatenated string in Bob.class. Imho this is bad practise.

I've stumbled on this bug by changing some constant's value in a library (a lib that was still under development and that had no release version yet), compiling a JAR from it and then deploying it into an application's lib directory. The application still used the value from the old version of the library's JAR ... since the application's JAR was compiled with the old library JAR.

Now try the same with a variable of a String. It works the same as primitive types (thus the value of the static String get's stored in the class that references it)! So the compiler does not decide based on whether the variable is of a primitive type or an Object (since both int and String "public static final" variables are stored within the referencing class.

But how can you get around this "feature" of the Sun JDK's compiler? In case of an integer value it's simple: use an Integer object instead of the int primitive type. We've already observed in our example that this works. But what about strings? We saw that the value of a constant String object was compiled into the referencing class's bytecode.

This whole stuff is some sort of "code optimization" on part of the Sun JDK compiler. Unfortunately I did not find any options/switches in the documenation of javac that could alter the default (imho buggy) behaviour (as most other compilers would allow me to do).

Btw. did you know about the javap class file disassembler that is shipped with JDK? It does not give you real java source code, but it's close enough so you can reverse-engineer the logic. I'm sure there're dozens of disassemblers (probably a few free/open-source ones too) that will give you full disassembly of a class file.

I've found a topic in Sun's forums on string optimization in javac. The only difference is that in my case the optimizer concatenates a value from an external class ... which can (and has a real chance to) change after the compilation of the referencing class. Looking at the mentioned forum post it seems that string optimization concatenates only up to the point til the string's value is "sure" to be constant. And after that point the remaining components are not optimized any further.

So my_string in a code like this:

will be optimized into this:

If my_var in the above example would be a "static final" variable, then the optimizer would have merged the whole bunch together in my_string into this:

(Btw. if you're interested in interpreting bytecode, read the Java Virtual Machine Specification. It's available online for free. You can even start building your own Java compiler based on that. )

A trivial "workaround" is to remove the "static final" keywords from the declaration of the variable and the optimizer will not merge its value into string concatenations. However this not a real alternative since it beats the whole point of using _constants_ (ie. if I remove "static final", then it's not a constant anymore ). It seems that "static final" String objects are optimized during string concatenation, because the compiler "knows" that their value won't change (String objects are immutable - there's no method to change their contents). But what about the "static final" Integer in my example? Integer is immutable too, isn't it? At least I did not find any methods in the Integer class that could modify the int that the object wraps around. So why are "static final" Integers not optimized in the same way? Maybe that's yet to come in a future version of javac.

Another trivial workaround: use objects instead of primitive types (and String) to store your constants. Eg. you could use Object and use specific type designators to improve on readability.
Eg. Alice could look like this:

All three notations result in the same Integer object, but the latter two are easier to recognize/read. And using Object will prevent the optimizer from merging their values during string concatenations since an Object might change during runtime (and the Object's toString() method's return value might change as well).

Of course you could just simply make sure that once you declare a "static final" constant in a class (and rely on its value in another class in a string concatenation), you never ever change the constant's value in the source code. To avoid the problem alltogether, I suggest you follow this simple rule: always recompile your code if you're intending to replace any libraries under it. Never replace a lib (ie. a JAR) in your application without recompiling your app. That should keep you safe.

To summerize this post: the Sun JDK javac compiler optimizes string concatenations. Class constants (variables declared as "static final") are subject to this optimization too and developers should be aware of that and work around it if necessary.

P.S.: I've checked and confirmed this behaviour to be present both in JDK 5 (Update 16) and JDK 6 (Update 10) on the Linux platform. I assume it's present in Sun JDKs on all platforms.