-
Bug
-
Resolution: Fixed
-
P5
-
8
Since JLS 3, 12.4.1 has included a rule for performing static initialization of top-level classes when an assert statement is executed:
"T is a top-level class, and an assert statement (§14.10) lexically nested within T is executed."
I am unable to reproduce this behavior:
-----
public class AssertInClass {
public static final java.io.PrintStream s = System.out.printf("initializing\n");
public static class C {
public void foo() { assert System.out.printf("foo assert\n") != null; }
public static void main(String... args) {
assert System.out.printf("main assert\n") != null;
new C().foo();
//new AssertInClass(); // uncommenting triggers initialization
System.out.println("done");
}
}
}
$ -> java7 -ea AssertInClass\$C
main assert
foo assert
done
// initialization never happens
-----
JVMS 5.5 does not directly account for this circumstance, so I assume the JLS rule was written with a certain implementation strategy in mind that would require some sort of access to the (initialized) outer class. It appears that this implementation strategy is not used, and perhaps never was.
I'd appreciate better historical context, but from what I can tell, it looks like this rule is simply wrong and should be removed.
"T is a top-level class, and an assert statement (§14.10) lexically nested within T is executed."
I am unable to reproduce this behavior:
-----
public class AssertInClass {
public static final java.io.PrintStream s = System.out.printf("initializing\n");
public static class C {
public void foo() { assert System.out.printf("foo assert\n") != null; }
public static void main(String... args) {
assert System.out.printf("main assert\n") != null;
new C().foo();
//new AssertInClass(); // uncommenting triggers initialization
System.out.println("done");
}
}
}
$ -> java7 -ea AssertInClass\$C
main assert
foo assert
done
// initialization never happens
-----
JVMS 5.5 does not directly account for this circumstance, so I assume the JLS rule was written with a certain implementation strategy in mind that would require some sort of access to the (initialized) outer class. It appears that this implementation strategy is not used, and perhaps never was.
I'd appreciate better historical context, but from what I can tell, it looks like this rule is simply wrong and should be removed.
- relates to
-
JDK-6394986 assert must cause the enclosing top level class to be initialized?
-
- Closed
-