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

[Eirik Bjørsnøs]

On Thu, Jan 29, 2026 at 1:05 AM Chen Liang <chen.l.liang at oracle.com> wrote:

> 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.
>

Interesting! :)

The key word here seems to be "determined". I wonder if we should interpret
this in context of the use of this term in the immediately preceding
paragraph:

An assert statement that is executed after its class or interface has
> completed initialization is enabled if and only if the *host system has
> determined* that the top level class or interface that lexically contains
> the assert statement enables assertions.


Perhaps we could/should interpret this as constraints on the host system,
rather than on any specific compiler implementation technique:

a) The host system must be ready to answer questions about the enabled
state no later than the initialization of any top level or nested class or
interface
b) The host system cannot change its mind about such questions.

In more concrete terms, this puts constraints on when
Class::desiredAssertionStatus can be expected to return reliable answers.

This more relaxed interpretation allows more freedom of implementation
while maintaining behavioral consistency.

Thought?

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