What does "T is a top-level class, and an assert statement lexically nested within T is executed." mean?

Question

I am learning the " Initialization of Classes and Interfaces", and it says "T is a top-level class, and an assert statement lexically nested within T is executed." Could any one tell me what does "T is a top-level class, and an assert statement lexically nested within T is executed." mean by a example?

This sentence is from JLS, and original text is like this :

A class or interface type T will be initialized immediately before the first occurrence of any one of the following:

• T is a class and an instance of T is created.
• T is a class and a static method declared by T is invoked.
• A static field declared by T is assigned.
• A static field declared by T is used and the field is not a constant variable (§4.12.4).
• T is a top-level class, and an assert statement (§14.10) lexically nested within T is executed.

Answer 1

I can give a partial explanation to it. It refers to enabling/disabling assertion. Assertion is enabled by -ea vm argument.

An important point about assert is:

An assert statement that is executed before its class has completed initialization is enabled.

Suppose -ea is not given and you run the below code:

 public class Q1 {
    public static void main(String[] args) {
        Bar b = new Bar();
    }
}
class Bar {
    static {
        boolean enabled = false;
        assert  enabled = false; //line(a)
        System.out.println("Asserts " + 
               (enabled ? "enabled" : "disabled"));
        System.out.println("as");
        Baz.testAsserts();
    }
}
class Baz extends Bar {
    static void testAsserts() {
        boolean enabled = false;
        assert  enabled = false;
        System.out.println("Asserts " + 
               (enabled ? "enabled" : "disabled"));
    }
}

In the above example when b is initialized, Java guarantees that before line(a) is called, the assertion is disabled (i.e. line(a) is not executed at all). Because assert enable/disable is a part of class initalization, hence it is mentioned in your shown statement in question.

The reason, why top-level class is mentioned and not every other class is this. More detailed behavior here:

public class Q1 {
    public static void main(String[] args) {
        Baz.testAsserts(); 
        // Will execute after Baz is initialized.
    }
}
class Bar {
    static {
        Baz.testAsserts();
        // Will execute before Baz is initialized!
    }
}
class Baz extends Bar {
    static void testAsserts() {
        boolean enabled = false;
        assert  enabled = false;
        System.out.println("Asserts " + 
               (enabled ? "enabled" : "disabled"));
    }
}

Even -ea flag is not used, still it throws an AssertionException. Here is what happens:

1. Q1.main is called
2. Q1.main calls Baz.testAsserts.
3. Because Baz extends Bar and Bar is not initialized, as per JLS it tries to initialize Bar
4. static block of Bar is called. Remember assert statement is enabled before its class has completed initialization or assert is called (which ever happens first). Which in this case is true at this stage as Bar is still not completely initialized
5. static of Bar calls Baz.testAsserts(). The assert is still enabled (remember disabling assertion has got to do with class initialization and Bar is still not completely initialized). Now Baz.testAsserts() throws AssertionException.

Above is a loop hole. JLS only guarantees that before executing any assert in Top level class, it will disable/enable (as whatever vm argument is given) it. But if it is not a top level class, then the behavior depends on the initialization of top-level class. To explain this, see this:

class Bar {
    static {
        //Baz.testAsserts();
        boolean enabled = false;
        assert  enabled = false;
        System.out.println("Asserts " + 
               (enabled ? "enabled" : "disabled"));
        // Will execute before Baz is initialized!
    }
}
class Baz extends Bar {
    static void testAsserts() {
        boolean enabled = false;
        assert  enabled = false;
        System.out.println("Asserts " + 
               (enabled ? "enabled" : "disabled"));
    }
}

This prints Asserts disabled Asserts disabled as Bar is well initialized. Bar initialization disables assert for the class and hence for Baz.

Answer 2

This is a top level class:

class TopLevel {
   ...
}

This is an assert statement:

assert( condition );

where condition is some boolean expression.

A is lexically nested into B, if it occurs inside the curly braces of B's definition. For example, fields, methods, static blocks are lexically nested in a class definition. Statements are lexically nested in methods or static blocks. Local definitions are nested in methods or blocks, that are itself nested in methods.

Hence an assert statement that is lexically nested in a top level class could be:

class A {
    static {
        assert ( 2+2 == 4 );
    }
}

Answer 3

I know how I would read this specification, but OpenJDK 1.7.0_40 does not behave as indicated, and neither does Oracle JDK 1.7.0_25.

A top level class is a class not nested inside any other. An assertion statement can occur in executable code, i.e. in a method, constructor or static initializer block. Most of these cases are handled by the other items: static methods are already covered, other methods as well as constructors fall under creation of an object of said class, and a static initializer block is part of the initialization process which is the result of any of the other events.

So the only way I can think of to have a lexically nested statement without triggering any of these cases would be via a nested class. E.g. something like this:

class Outer {
    static {
        System.out.println("Outer initialized");
    }
    static class Nested {
        static void foo() {
            assert System.out == null;
        }
    }
}

But if I run Outer.Nested.foo() with enabled assertions then I get the assertion error (so the statement got executed) but not the Outer initialized message. So the top level class was not initialized, even though a lexically nested assert statement got executed.

Either I'm misunderstanding the specification here, or the mentioned implementations don't follow it.

As for the rationale: I think that the main point of this requirement is the fact that enabling and disabling assertions is implemented via a hidden static (and iirc. final) field of the class. So when the assert statement gets executed, it has to check that field, hence that field has to be initialized, hence the class has to be initialized. But in the above code, the relevant field is likely that of Outer.Nested, not that of Outer itself. So it makes sense that Outer doesn't have to be initialized at that point. But apart from the above construct, I can not think of a case where the last rule would apply but none of the other rules.

Answer 4

You have linked to section 12.4.1 of the JLS for Java 7.

In java bug JDK-8043189 "12.4.1: Should asserts trigger initialization of outer classes?" there is a comment explaining that the last bullet of the list, which reads "T is a top-level class, and an assert statement (§14.10) lexically nested within T is executed" is simply wrong, and it had been erroneously inserted into the JLS back in version 6, and it stayed there until version 7 simply because nobody noticed it.

I found that the statement was still there in the JLS for Java 8, but it has finally been removed from paragraph 12.4.1 of the JLS for Java 9.

So, bottom line is, do not try to make any sense out of it, because there is none to be made; it is not a true statement, and it never was.