<div dir="ltr"><div dir="ltr">On Thu, Jan 29, 2026 at 7:40 AM Eirik Bjørsnøs <<a href="mailto:eirbjo@gmail.com">eirbjo@gmail.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 dir="ltr"><div dir="ltr">Perhaps we could/should interpret this as constraints on the host system, rather than on any specific compiler implementation technique:</div></div></blockquote><div><br></div><div>This sent me down a rabbit hole of javac homework and prototyping. Here's some takeaways:</div><div><br></div><div><b>ConstantDynamic is maybe not a great fit</b></div><div><br></div><div>I prototyped using condy to resolve assertion status. Causes early bootstrap issues and circularity issues for code using assert in anything called from ConstantDynamic machinery. So probably not useful in java.base. Benchmarking indicates performance is neutral vs current synthetic field. </div><div><br></div><div>And: JLS seems to tie assertion status to class initialization status, so we need to track this state anyhow (so we are not really dealing with a constant).</div><div><br></div><div><b>Observation: Current javac implementation violates JLS</b></div><div><b><br></b></div><div>The JSL states that <i>Whether a top level class or interface enables assertions cannot be changed after it has been determined.</i></div><div><i><br></i></div><div>The following code demonstrates how to change the assertion status of a Nested class after its top level class has been initialized:</div><div><b><br></b></div><div><font face="monospace">public interface AfterToplevelInit {<br>    public static class Nested {<br>        void m() {<br>            assert false;<br>        }<br>    }<br>    // Fails with AssertionError when run with -da<br>    public static void main(String[] args) {<br>        ClassLoader cl = AfterToplevelInit.class.getClassLoader();<br>        cl.setClassAssertionStatus(AfterToplevelInit.class.getName(), true);<br>        new Nested().m();<br>    }<br>}</font><b></b></div><div> </div><div><b>Solution: Should the determined assertion status be tracked by java.lang.Class?</b></div><div><b><br></b></div><div>I prototyped adding a field Class::assertionStatus. Querying this status will  determine the assertion status of the class such that once queried, the answer never changes.</div><div><br></div><div>Moving this state to Class helps us fix the above JLS violation (since in contrast with synthetic fields, this state of the top level class will be visible across all nestmates) </div><div><br></div><div>This solution also allows us to prevent the forced initialization of the synthetic class during interface static initializers. We can instead call determineAssertionStatus() on the top level class to "seal" the determination of the assertion status. Saves us extra class loading when using asserts in unused interface default/static methods.</div><div><br></div><div>My "exactly-once" (benign data race) initialization query method in java.lang.Class looks like this:</div><div><br></div><font face="monospace">public boolean determineAssertionStatus() {<br>    byte status = this.assertionStatus;<br>    if (status == 0) {<br>        if (desiredAssertionStatus()) {<br>            this.assertionStatus = 1;<br>            return true;<br>        } else {<br>            this.assertionStatus = -1;<br>            return false;<br>        }<br>    }<br>    return status == 1;<br></font><div><font face="monospace">}</font> </div><div><br></div><div><br></div><div>Cheers,</div><div>Eirik.</div></div></div>