The java language specification is a little difficult to follow on final static
fields.
The best place to look is 13.4.8 - Binary Compatability. This says
"We call a field that is static, final, and initialized with a compile-time
constant expression a primitive constant."
and it is implicit in the following discussion that such values are always
inlined.
So these are exactly the constants that Kontorotsui is looking for, and as Chris
says there is a bug in the compiler - but not in Suns compiler, which is quite
happy with
the example.
BTW, the variable v doesn't need to be final in this particular example,
and the spec. recommends that it should not be, for binary compatibility reasons.
But if you want the constant behaviour of final then probably "private static
final"
is the best solution. If such constants are put in a separate class as Chris
suggests
then if the value is changed you have to be careful to recompile EVERY class that
references them.
Nick
Chris Abbey wrote:
> At 11:05 AM 7/16/99 +0200, Kontorotsui wrote:
> >
> >On 14-Jul-99 Michael Sinz wrote:
> >> The reason is that until the constructor is called, no instance data
> >> can be used. Note that you did not make this static final but rather
> >> final. This means there must be actual instance data to access this
> >> variable and that does not exist until super() returns since until
> >> that point in time *no* instance data space was allocated (let alone
> >> initialized)
> >
> >Ok, but it doesn't work either with static final.
>
> Then there is a bug in javac... http://java.sun.com/cgi-bin/bugreport.cgi
>
> Jikes will accept the following code:
> class aSuperClass {
> aSuperClass(int i) {
> System.out.println("aSupperClass("+i+")");
> }
> }
> class aClass extends aSuperClass {
> static final int v = 1;
> aClass() {
> super(v);
> System.out.println("aClass()");
> }
> }
> class mainline {
> public static void main(String[] a) {
> new aClass();
> }
> }
>
> and the result of a run is:
> aSupperClass(1)
> aClass()
>
> >> Actually, unless it is statis final it is not a real constant.
> >> And even static final is a variable, it just happens to be unchangeable.
> >
> >Ok, then what is missing is a real constant in Java, something useful only
> for
> >the code writer and that can be automatically substituted by the
> preprocessor.
>
> Actually with the way class files are designed there either really is no
> such thing, or everything is like that. (it depends on your POV.) I tend
> to view it as "static final is #DEFINE" when it comes to primitives; objects
> are different! For example, the aClass above disassembles into :
>
> Method aClass()
> 0 aload_0
> 1 iconst_1
> 2 invokespecial #15 <Method aSuperClass(int)>
> 5 getstatic #21 <Field java.io.PrintStream out>
> 8 ldc #23 <String "aClass()">
> 10 invokevirtual #29 <Method void println(java.lang.String)>
> 13 return
>
> iconst_1 is a bytecode special item because numbers like 0 and 1 occur SO
> often in code that they have special bytecode representation; there is one
> for each of -1..5. If I make that 1024 instead...
>
> Method aClass()
> 0 aload_0
> 1 sipush 1024
> 4 invokespecial #15 <Method aSuperClass(int)>
> 7 getstatic #21 <Field java.io.PrintStream out>
> 10 ldc #23 <String "aClass()">
> 12 invokevirtual #29 <Method void println(java.lang.String)>
> 15 return
>
> As you can see the value 1024 is "hard coded" into the bytecode just like
> you want.
>
> [...]
> >As you see the lack of a real constant forces me to manually put 15 in the
> >constructor and in the for upper bound. This is bad because if one day I want
> >the 15 to be a 18, I'll have to remember to change it also in the for.
>
> Make it "static final int MYCONST=18;" and get a better compiler.
>
> Another option is to put it in another class... for example a project I
> work on has a class CONST in each package which is final and contains
> nothing but static finals fields; then you code super(CONST.someproperty);
> In theory these are all package wide constants... and there are similar
> classes in all packages, including superpackages.
>
----------------------------------------------------------------------
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
