<div dir="ltr"><div dir="ltr">On Thu, Jan 29, 2026 at 1:05 AM Chen Liang <<a href="mailto:chen.l.liang@oracle.com">chen.l.liang@oracle.com</a>> wrote:</div><div class="gmail_quote gmail_quote_container"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="msg2541799974436307506"><div dir="ltr">
<div style="font-family:"Calibri Light","Helvetica Light",sans-serif;color:rgb(0,0,0)">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.</div></div></div></blockquote><div><br></div><div>Interesting! :)</div><div><br></div><div>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:</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">An assert statement that is executed after its class or interface has completed initialization is enabled if and only if the <b>host system has determined</b> that the top level class or interface that lexically contains the assert statement enables assertions.</blockquote><div> </div><div>Perhaps we could/should interpret this as constraints on the host system, rather than on any specific compiler implementation technique:</div><div><br></div><div>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</div><div>b) The host system cannot change its mind about such questions.</div><div><br></div><div>In more concrete terms, this puts constraints on when Class::desiredAssertionStatus can be expected to return reliable answers.</div><div><br></div><div>This more relaxed interpretation allows more freedom of implementation while maintaining behavioral consistency.</div><div><br></div><div>Thought?</div><div><br></div><div>Thanks,</div><div>Eirik.</div><div><br></div></div></div>