«

Roedy Green wrote:
>
> what term do you use to distinguish been a constant like this:
>
> private static final int X = Math.min(2,1);
>
> and like this:
>
> private static final int Y = 42;
>
>
> The second is known at compile time, can be used in case labels, is
> in-lineable.

The first is really just a static final, colloquially known as a
constant. The latter is a "compile-time constant expression" according
to the JLS 3rd Ed, 15.28, p525. I believe the second edition has some
errata in that section about the use (or not) of nulls.


There's some non-normative discussion about enum static initialisation
in section 8.9 (Enums!), p252.

Tom Hawtin
--
Unemployed English Java programmer
http://jroller.com/page/tackline/

On Fri, 26 Aug 2005 20:39:17 +0100, Thomas Hawtin
<> wrote or quoted :

>I don't think you should depend upon your decompiler being accurate.
>javap -c is the way to go. You can see that the actual byte code is
>different from what your decompiler is claiming.

You are such a clever character. You are right yet again. The
compiler indeed does the static field inits AFTER the constructor
calls. If it reversed the order, the way DJ decompiles it, Java would
have no problem with static references in constructors.

Here is the Javap decompilation of Final.java


javap -c Final

Compiled from "Final.java"
final class Final extends java.lang.Enum{
public static final Final X;

public static final Final[] values();
Code:
0: getstatic #1; //Field $VALUES:[LFinal;
3: invokevirtual #2; //Method
"[LFinal;".clone)Ljava/lang/Object;
6: checkcast #3; //class "[LFinal;"
9: areturn

public static Final valueOf(java.lang.String);
Code:
0: ldc_w #4; //class Final
3: aload_0
4: invokestatic #5; //Method
java/lang/Enum.valueOfLjava/lang/Class;Lj
ava/lang/StringLjava/lang/Enum;
7: checkcast #4; //class Final
10: areturn

static {};
Code:
0: new #4; //class Final
3: dup
4: ldc #7; //String X
6: iconst_0
7: invokespecial #8; //Method "<init>"Ljava/lang/String;I)V
10: putstatic #9; //Field X:LFinal;
13: iconst_1
14: anewarray #4; //class Final
17: dup
18: iconst_0
19: getstatic #9; //Field X:LFinal;
22: aastore
23: putstatic #1; //Field $VALUES:[LFinal;
26: iconst_2
27: iconst_1
28: invokestatic #10; //Method java/lang/Math.minII)I
31: putstatic #11; //Field x:I
34: return

}























































































































































































--
Canadian Mind Products, Roedy Green.
http://mindprod.com Again taking new Java programming contracts.

Roedy Green wrote:
> On Fri, 26 Aug 2005 20:39:17 +0100, Thomas Hawtin
> <> wrote or quoted :
>
>
>>I don't think you should depend upon your decompiler being accurate.
>>javap -c is the way to go. You can see that the actual byte code is
>>different from what your decompiler is claiming.
>
>
> You are such a clever character. You are right yet again. The
> compiler indeed does the static field inits AFTER the constructor
> calls. If it reversed the order, the way DJ decompiles it, Java would
> have no problem with static references in constructors.
>

But there would be problems with static references to the enum values,
don't you think? So this may be a damned if do you, damned if you don't
type situation.

Ray

--
XML is the programmer's duct tape.

On Sat, 27 Aug 2005 01:40:26 GMT, Raymond DeCampo
<> wrote or quoted :

>But there would be problems with static references to the enum values,
>don't you think? So this may be a damned if do you, damned if you don't
>type situation.
Ah ha!

To solve that one you would need some sort of spread-sheet like
natural ordering of the initialisations which would be very
unJava-like.

But then you'd think you could SET static values in constructors, just
not reference them. Perhaps that is how it does work.

I also want to recheck what their thinking is on compile time static
constants.

I suppose you get into similar situation if you have a pair of classes
whose static inits cross reference each other. It is just that Java
does not warn you of the problems.
--
Canadian Mind Products, Roedy Green.
http://mindprod.com Again taking new Java programming contracts.

On Fri, 26 Aug 2005 20:51:14 +0100, Thomas Hawtin
<> wrote or quoted :

>constant. The latter is a "compile-time constant expression" according
>to the JLS 3rd Ed, 15.28, p525. I believe the second edition has some
>errata in that section about the use (or not) of nulls.

I have written an essay on what I have discovered about constants.
Other that the usual error checking, I invite you to submit some
counter-intuitive examples on what is compile-time and what is a
load-time constant.

see http://mindprod.com/jgloss/constants.html
--
Canadian Mind Products, Roedy Green.
http://mindprod.com Again taking new Java programming contracts.