Compiled classes caching constant values?

Question

I have a question about switching the version of a library at runtime. Specifically, if I compile a class against a particular version of a library, then use a different version at runtime, what behaviour should I expect? What I'm seeing is very unintuitive, and I'm hoping someone can shed some light.
I have a class which defines constant values:
public class LibraryClass {
   public static final String CONST_STRING = "11111";
   public static final Integer CONST_INTEGER = new Integer(11111);
   public static final int CONST_INT = 11111;
}Let's say I compile this class and package it in a jar called library.jar.
Then I create another class that uses this library:
public class MyTest {
   public static void main(String[] args) throws Exception {
      System.out.println(LibraryClass.CONST_STRING);
      System.out.println(LibraryClass.CONST_INTEGER);
      System.out.println(LibraryClass.CONST_INT);
}With library.jar in the classpath, I compile MyTest.java and then run it, and I see what I would expect:
11111
11111
11111Then I create a second version of my library, with different values:
public class LibraryClass {
   public static final String CONST_STRING = "22222";
   public static final Integer CONST_INTEGER = new Integer(22222);
   public static final int CONST_INT = 22222;
}I compile this new class and package it in library2.jar.
Now, without recompiling MyTest, I run MyTest with library2.jar in the classpath, and get the output:
11111
22222
11111The String and int values seem to be cached in the compiled class (MyTest), which I find strange. When I add accessor methods to LibraryClass and call these from MyTest, it works as I would expect - i.e. it always prints the values from the version of the library included at runtime, regardless of the version used at compile time.
It seems like these values are stored in the binary class file of MyTest - why is this? And why does the Integer value work correctly when the others don't?
Thanks,
Steve

Answer 1

stevej wrote:
jschell wrote:
Because that is an expresson not a constant.
You can make the other two work the same with the following code (pseudo)
public static final String CONST_STRING = "11111".toString();
public static final int CONST_INT = new Integer(11111).intValue();Hmm it works... So it depends how the constants are defined? I don't see why the compiler would make the distinction... well I do sort of. But since the constants I'm working with are defined in a 3rd party library I can't change the way they are defined anyway.They are expressions. They are not set until the code runs.
The original way they are literals. The compiler knows they are literals so it can optimize for it.