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

[Chen Liang]

Hi David, a dynamic constant does have the advantage of bypassing some circular initialization issues. However, such a constant still must be initialized by the time the class finishes initialization. The benefits of a dynamic constant are not helpful unless we adjust the JLS. In addition, a synthetic field can be accessed by other classes and interfaces in the same nest; not so for dynamic constants without an accessor method.
________________________________
From: compiler-dev <compiler-dev-retn at openjdk.org> on behalf of David Lloyd <david.lloyd at redhat.com>
Sent: Wednesday, January 28, 2026 3:43 PM
To: Eirik Bjørsnøs <eirbjo at gmail.com>
Cc: compiler-dev at openjdk.org <compiler-dev at openjdk.org>
Subject: Re: Q: Why are $assertionsDisabled nested classes loaded eagerly by interface static initializers?

On the same token, maybe it's worth considering going farther, and making assertion status determination use a dynamic constant instead of a synthetic field?

On Wed, Jan 28, 2026 at 3:36 PM Eirik Bjørsnøs <eirbjo at gmail.com<mailto:eirbjo at gmail.com>> wrote:

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.


--
- DML • he/him
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20260129/df23d63c/attachment.htm>