问题
Someone explain to me the differences between the following two statements?
A static final
variable initialized by a static
code block:
private static final String foo;
static { foo = "foo"; }
A static final
variable initialized by an assignment:
private static final String foo = "foo";
回答1:
In this example, there's one subtle difference - in your first example, foo
isn't determined to be a compile-time constant, so it can't be used as a case in switch
blocks (and wouldn't be inlined into other code); in your second example it, is. So for example:
switch (args[0]) {
case foo:
System.out.println("Yes");
break;
}
That's valid when foo
is deemed to be a constant expression, but not when it's "just" a static final variable.
However, static initializer blocks are usually used when you have more complicated initialization code - such as populating a collection.
The timing for initialization is described in JLS 12.4.2; any static final fields which are considered as compile-time constants are initialized first (step 6) and initializers are run later (step 9); all initializers (whether they're field initializers or static initializers) are run in textual order.
回答2:
private static final String foo;
static { foo ="foo";}
The value of foo
is initialized when the class is loaded and static initializers are run.
private static final String foo = "foo";
Here, the value of foo
will be a compile-time constant. So, in reality "foo"
will be available as part of th byte-code itself.
回答3:
In IInd case- value of foo is early bind ie compiler identifies and assign value foo to variable FOO
, which cant be changed,and this will be available apart with byte-code itself.
private static final String FOO = "foo";
and In Ist case-value of foo initialize just after class loading as a very first assignment before instance variable assigned,also here you can catch exceptions or static field can be assign by calling static methods in static block.
private static final String FOO;
static { FOO ="foo";}
So whenever there is a condition arrive when compiler must have to identify the value of variable foo, condition II will work,for ex-like value of case: in switch cases.
回答4:
The JLS describes a few special behaviors of what it calls constant variables, which are final
variables (whether static
or not) which are initialized with constant expressions of String
or primitive type.
Constant variables have a major difference with respect to binary compatibility: the values of constant variables become part of the class's API, as far as the compiler is concerned.
An example:
class X {
public static final String XFOO = "xfoo";
}
class Y {
public static final String YFOO;
static { YFOO = "yfoo"; }
}
class Z {
public static void main(String[] args) {
System.out.println(X.XFOO);
System.out.println(Y.YFOO);
}
}
Here, XFOO
is a "constant variable" and YFOO
is not, but they are otherwise equivalent. Class Z
prints out each of them. Compile those classes, then disassemble them with javap -v X Y Z
, and here is the output:
Class X:
Constant pool:
#1 = Methodref #3.#11 // java/lang/Object."<init>":()V
#2 = Class #12 // X
#3 = Class #13 // java/lang/Object
#4 = Utf8 XFOO
#5 = Utf8 Ljava/lang/String;
#6 = Utf8 ConstantValue
#7 = String #14 // xfoo
#8 = Utf8 <init>
#9 = Utf8 ()V
#10 = Utf8 Code
#11 = NameAndType #8:#9 // "<init>":()V
#12 = Utf8 X
#13 = Utf8 java/lang/Object
#14 = Utf8 xfoo
{
public static final java.lang.String XFOO;
descriptor: Ljava/lang/String;
flags: ACC_PUBLIC, ACC_STATIC, ACC_FINAL
ConstantValue: String xfoo
X();
descriptor: ()V
flags:
Code:
stack=1, locals=1, args_size=1
0: aload_0
1: invokespecial #1 // Method java/lang/Object."<init>":()V
4: return
}
Class Y:
Constant pool:
#1 = Methodref #5.#12 // java/lang/Object."<init>":()V
#2 = String #13 // yfoo
#3 = Fieldref #4.#14 // Y.YFOO:Ljava/lang/String;
#4 = Class #15 // Y
#5 = Class #16 // java/lang/Object
#6 = Utf8 YFOO
#7 = Utf8 Ljava/lang/String;
#8 = Utf8 <init>
#9 = Utf8 ()V
#10 = Utf8 Code
#11 = Utf8 <clinit>
#12 = NameAndType #8:#9 // "<init>":()V
#13 = Utf8 yfoo
#14 = NameAndType #6:#7 // YFOO:Ljava/lang/String;
#15 = Utf8 Y
#16 = Utf8 java/lang/Object
{
public static final java.lang.String YFOO;
descriptor: Ljava/lang/String;
flags: ACC_PUBLIC, ACC_STATIC, ACC_FINAL
Y();
descriptor: ()V
flags:
Code:
stack=1, locals=1, args_size=1
0: aload_0
1: invokespecial #1 // Method java/lang/Object."<init>":()V
4: return
static {};
descriptor: ()V
flags: ACC_STATIC
Code:
stack=1, locals=0, args_size=0
0: ldc #2 // String yfoo
2: putstatic #3 // Field YFOO:Ljava/lang/String;
5: return
}
Class Z:
Constant pool:
#1 = Methodref #8.#14 // java/lang/Object."<init>":()V
#2 = Fieldref #15.#16 // java/lang/System.out:Ljava/io/PrintStream;
#3 = Class #17 // X
#4 = String #18 // xfoo
#5 = Methodref #19.#20 // java/io/PrintStream.println:(Ljava/lang/String;)V
#6 = Fieldref #21.#22 // Y.YFOO:Ljava/lang/String;
#7 = Class #23 // Z
#8 = Class #24 // java/lang/Object
#9 = Utf8 <init>
#10 = Utf8 ()V
#11 = Utf8 Code
#12 = Utf8 main
#13 = Utf8 ([Ljava/lang/String;)V
#14 = NameAndType #9:#10 // "<init>":()V
#15 = Class #25 // java/lang/System
#16 = NameAndType #26:#27 // out:Ljava/io/PrintStream;
#17 = Utf8 X
#18 = Utf8 xfoo
#19 = Class #28 // java/io/PrintStream
#20 = NameAndType #29:#30 // println:(Ljava/lang/String;)V
#21 = Class #31 // Y
#22 = NameAndType #32:#33 // YFOO:Ljava/lang/String;
#23 = Utf8 Z
#24 = Utf8 java/lang/Object
#25 = Utf8 java/lang/System
#26 = Utf8 out
#27 = Utf8 Ljava/io/PrintStream;
#28 = Utf8 java/io/PrintStream
#29 = Utf8 println
#30 = Utf8 (Ljava/lang/String;)V
#31 = Utf8 Y
#32 = Utf8 YFOO
#33 = Utf8 Ljava/lang/String;
{
Z();
descriptor: ()V
flags:
Code:
stack=1, locals=1, args_size=1
0: aload_0
1: invokespecial #1 // Method java/lang/Object."<init>":()V
4: return
public static void main(java.lang.String[]);
descriptor: ([Ljava/lang/String;)V
flags: ACC_PUBLIC, ACC_STATIC
Code:
stack=2, locals=1, args_size=1
0: getstatic #2 // Field java/lang/System.out:Ljava/io/PrintStream;
3: ldc #4 // String xfoo
5: invokevirtual #5 // Method java/io/PrintStream.println:(Ljava/lang/String;)V
8: getstatic #2 // Field java/lang/System.out:Ljava/io/PrintStream;
11: getstatic #6 // Field Y.YFOO:Ljava/lang/String;
14: invokevirtual #5 // Method java/io/PrintStream.println:(Ljava/lang/String;)V
17: return
}
Things to notice in the disassembly, which tell you the differences between X
and Y
run deeper than syntactic sugar:
XFOO
has a ConstantValue attribute, signifying that its value is a compile-time constant. WhereasYFOO
does not, and uses astatic
block with aputstatic
instruction to initialize the value at runtime.The
String
constant"xfoo"
has become part of classZ
's constant pool, but"yfoo"
has not.Z.main
uses theldc
(load constant) instruction to load"xfoo"
onto the stack directly from its own constant pool, but it uses agetstatic
instruction to load the value ofY.YFOO
.
Other differences you will find:
If you change the value of
XFOO
and recompileX.java
but notZ.java
, you have a problem: classZ
is still using the old value. If you change the value ofYFOO
and recompileY.java
, classZ
uses the new value whether you recompileZ.java
or not.If you delete the
X.class
file entirely, classZ
still runs correctly.Z
has no runtime dependency onX
. Whereas if you delete theY.class
file, classZ
fails to initialize with aClassNotFoundException: Y
.If you generate documentation for the classes with javadoc, the "Constant Field Values" page will document the value of
XFOO
, but not the value ofYFOO
.
The JLS describes the above effects constant variables have on compiled class files in §13.1.3:
A reference to a field that is a constant variable (§4.12.4) must be resolved at compile time to the value V denoted by the constant variable's initializer.
If such a field is
static
, then no reference to the field should be present in the code in a binary file, including the class or interface which declared the field. Such a field must always appear to have been initialized (§12.4.2); the default initial value for the field (if different than V) must never be observed.If such a field is non-
static
, then no reference to the field should be present in the code in a binary file, except in the class containing the field. (It will be a class rather than an interface, since an interface has onlystatic
fields.) The class should have code to set the field's value to V during instance creation (§12.5).
And in §13.4.9:
If a field is a constant variable (§4.12.4), and moreover is
static
, then deleting the keywordfinal
or changing its value will not break compatibility with pre-existing binaries by causing them not to run, but they will not see any new value for a usage of the field unless they are recompiled.[...]
The best way to avoid problems with "inconstant constants" in widely-distributed code is to use
static
constant variables only for values which truly are unlikely ever to change. Other than for true mathematical constants, we recommend that source code make very sparing use ofstatic
constant variables.
The upshot is that if your public library exposes any constant variables, you must never change their values if your new library version is otherwise supposed to be compatible with code compiled against old versions of the library. It won't necessarily cause an error, but the existing code will probably malfunction since it will have outdated ideas about the values of constants. (If your new library version needs for classes which use it to be recompiled anyway, then changing constants doesn't cause this problem.)
Thus, initializing a constant with a block gives you more freedom to change its value, because it prevents the compiler embedding the value into other classes.
回答5:
The only difference is the initialization time.
Java first initializes the members and then the static blocks.
回答6:
An additional aspect: Consider the case when you have multiple static fields, and yes this is a corner case...
As stated in Jon Skeet's answer, the JLS defines the exact order of initialization. However, if for some reason you have to initialize multiple static attributes in a specific order, you may want to make the initialization sequence clearly visible in the code. When using direct field initialization: Some code formatters (and developers) may decide at some point to sort fields differently, this will directly impact how the fields get initialized and introduce unwanted effects.
By the way, if you want to follow common java coding conventions, you should use capital letters when defining 'constants' (final static fields).
--- edited reflecting Jon Skeet's comments ---
回答7:
Static block give you more than simple statement. In this particular case is the same thing. Static section will be executed at class load time, before any instances constructed. You can call methods here and assign their results to static fields. And you can catch exceptions in static blocks.
来源:https://stackoverflow.com/questions/29691513/difference-between-static-modifier-and-static-block