Static Import in JDK 5

[Jobin Babu]

Hi All,

I am facing a strange scenario in JDK 1.5

I have a constant class with variable

public static final String STATUS="ERROR";

I imported the STATUS variable in another class using static import (Let’s say the Class Name as A). I compiled both classes and executed. Later I changed the STATUS value into "SUCCESS". I re-compiled the Constant class and executed again. But the change is not reflecting in the class A. Later I recompiled class A and it’s started working. Any idea what’s the necessary to compile the class A??

Any suggestions on this??

Thanks in Advance
Jobin

[Rob Spoor]

For compile time constants, which include Strings, primitives, and any String / primitive created by applying operators on them (e.g. + for String concatenation, mathematical operators), the compiler has a tendency to replace calls to those constants to their actual values.
So the compiled class A did not make a call to Constant.STATUS, but actually includes the string value "ERROR".

If you know the constants are going to change, you can use a static initializer block:

public class Constant
{
public static final String STATUS;
static
{
STATUS = "ERROR";
}
}

Because the initialization of STATUS is separated from the declaration, the compiler no longer does the substitution but will look for the latest value each time.

Note that you need to initialize the "constant" in a static block, otherwise the code won't compile because STATUS may not be initialized.

[Campbell Ritchie]

It is worthwhile doing a javap call on the .class file. Try javap -c MyClass and you can see whether the compile-time constants have been "inlined." As Rob said, the compiler "doesn't expect the values to change."

[Jobin Babu]

This is happening in one of my Real time application. I am using this contant in more than a dozen of classes. Its not a good idea to go and re-compile all the classes.

I beleive it is indirectly preventing the concept of "Reusability" ???

[Ernest Friedman-Hill]

It's documented and well-known behavior, and Rob describes a simple and well-known approach to "fixing" it if you must.

[Marky Vasconcellos]

Final objects can't have it value changed.

If you have a lot of static imports and final Strings like that maybe it should be time for some refactoring..

You never thinked about have an Singleton who stores variables like that to use in all the program?
It's a solution.. and some others.

[Tom Johnson]

Ah can you explain this Rob?

If you know the constants are going to change, you can use a static initializer block:

1. public class Constant
2. {
3. public static final String STATUS;
4.
5. static
6. {
7. STATUS = "ERROR";
8. }
9. }

I dont get it....how can the value of the STATUS variable change? Its marked final ?

Thanks

[Ernest Friedman-Hill]

 

Tom Johnson wrote:Ah can you explain this Rob?


I dont get it....how can the value of the STATUS variable change? Its marked final ?

Read the original post in this thread. We're talking about what happens when the code is edited and a new value is used, then this class is recompiled, but other classes aren't.

[Rob Spoor]

It isn't changed, it's just set in a different way.

The static initializer block is called only once, when the class is initialized. Because it is only called once STATUS only has its value set once, just like with the declare+initialize combination. The class initialization is guaranteed to complete, including all static initializer blocks, before any of its methods is called or any of its fields is evaluated, so by the time some outside class calls Constant.STATUS, this field has its only value set.
But because the declaration and initialization are split, the compiler does not know its value, and therefore cannot replace it in calling code. This is why in this example STATUS is not a so-called compile time constant but a runtime constant. If you need more info on the difference, use our search - there was a real big discussion on it last year.

[Tom Johnson]

Ah right OK thanks guys