Q: Why are $assertionsDisabled nested classes loaded eagerly by interface static initializers?

[Chen Liang]

Hi Eirik, this is required by the JLS 14.10 The assert Statement.

> Whether a top level class or interface enables assertions is determined no later than the earliest of (i) the initialization of the top level class or interface, and (ii) the initialization of any class or interface nested in the top level class or interface. Whether a top level class or interface enables assertions cannot be changed after it has been determined.

The reason why interfaces use a synthetic class to store $assertionDisabled is because interfaces cannot declare non-public static final fields.

Regards,
Chen Liang
________________________________
From: compiler-dev <compiler-dev-retn at openjdk.org> on behalf of Eirik Bjørsnøs <eirbjo at gmail.com>
Sent: Wednesday, January 28, 2026 3:35 PM
To: compiler-dev at openjdk.org <compiler-dev at openjdk.org>
Subject: Q: Why are $assertionsDisabled nested classes loaded eagerly by interface static initializers?


Hi,

Since interfaces cannot have private fields, javac needs to generate a synthetic inner class to hold the $assertionsDisabled field.

A static initializer is also added to the interface, eagerly initializing the nested class, see the java.util.zip.Checksum for an example:

 static {};
    Code:
         0: getstatic     #16                 // Field java/util/zip/Checksum$1.$assertionsDisabled:Z
         3: ifeq          6
         6: return

What is the purpose of this eager initialization in Lower::assertFlagTest? I would presume a lazy initialization of the nested class on the first run of an assert would be sufficient?

In fact when I remove this eager initialization, assertions seem to load the nested class just fine with -esa enabled, but avoid loading the nested class with assertions disabled.

Asking because this would save class loading common scenarios where the default method is always overridden and thus the default method with the assert is never executed.

Can we load these nested synthetic classes lazily?

Cheers,
Eirik.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20260129/bbfa982e/attachment-0001.htm>