<div dir="ltr">Hello all,<br><br>Thanks again for the thoughtful discussion so far. Based on the thread I’d like to suggest a practical, non-breaking way forward that gives teams the <b>option </b>to enforce instance-qualified static access as a hard rule, while preserving backward compatibility for everyone else.<br><br><b>Proposal (summary)</b><br>Provide an opt-in enforcement stack consisting of:<br>  1. A reference <b>javac plugin</b> (e.g. StaticAccessEnforcer) that fails compilation on instance-qualified static accesses when enabled;<br>  2. companion <b>Maven/Gradle plugins</b> that automatically enable the plugin for projects that add the dependency or set a property;<br>  3. <b>IDE quick-fixers</b> and a command-line <b>codemod</b> to assist automated migration; and<br>  4. when/if available, recommend using per-category Werror (e.g. `-Werror:static`) for CI once OpenJDK supports it broadly.<br><br><b>Why this approach?</b><br>  - <b>No language break</b> — default javac behavior remains unchanged.  <br>  - <b>Opt-in</b> — new projects or teams can opt to treat the warning as an error by adding a dependency/flag.  <br>  - <b>Ecosystem friendly</b> — leverages javac plugin SPI, Checker Framework/ErrorProne patterns, and IDE support. :contentReference[oaicite:11]{index=11}<br><br><b>Implementation sketch</b><br>  - Build reference plugin using the `Plugin` SPI and publish as a Maven artifact. Example invocation: `javac -Xplugin:StaticAccessEnforcer ...` or via maven-compiler-plugin/Gradle compiler args. :contentReference[oaicite:12]{index=12}<br>  - Provide a `static-access-enforcer` Gradle/Maven plugin that wires the `-Xplugin` or annotation processor automatically.<br>  - Include automated codemod tooling (JavaParser/Eclipse JDT) and an IntelliJ quick-fix to perform safe replacements.<br>  - Plugin modes: `report` / `warn` / `error`, and support `@SuppressWarnings("static")` or per-file exclusion.<br><br><b>Request</b><br>If this sounds reasonable, I can prepare:<br>  - a small reference implementation (javac plugin + sample Maven config), and<br>  - a short JEP-style note describing migration story and sample fixes.<br><br>Thank you for considering this compromise — it preserves Java’s compatibility guarantees while giving teams a practical path to stronger, enforced conventions.<br><br>Kind regards,  <br>Kamlesh<br></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Sun, 25 Jan 2026 at 11:04, Chen Liang <<a href="mailto:chen.l.liang@oracle.com">chen.l.liang@oracle.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="msg-6008024249066475556">




<div dir="ltr">
<div style="font-family:"Calibri Light","Helvetica Light",sans-serif;font-size:12pt;color:rgb(0,0,0)">
Referring to the "bureaucratic process": Note amber is related to language specification, which is extremely sensitive to addition due to compatibility and almost no ability to rollback a wrong decision once it has been made. (Consider a counterexample of ?:'s
 null-long merge to Long, and Long-long merge back to long, causing NPE)</div>
<div style="font-family:"Calibri Light","Helvetica Light",sans-serif;font-size:12pt;color:rgb(0,0,0)">
<br>
</div>
<div style="font-family:"Calibri Light","Helvetica Light",sans-serif;font-size:12pt;color:rgb(0,0,0)">
> how to start if I believe a feature (even if small) should be implemented in the JDK (or related tools).</div>
<div style="font-family:"Calibri Light","Helvetica Light",sans-serif;font-size:12pt;color:rgb(0,0,0)">
<br>
</div>
<div style="font-family:"Calibri Light","Helvetica Light",sans-serif;font-size:12pt;color:rgb(0,0,0)">
The JDK is not eager to add features too - it means the JDK has to support it decades later, and a feature must interact with the rest of the features, which can exponentially increase the complexity.</div>
<div style="font-family:"Calibri Light","Helvetica Light",sans-serif;font-size:12pt;color:rgb(0,0,0)">
<br>
</div>
<div style="font-family:"Calibri Light","Helvetica Light",sans-serif;font-size:12pt;color:rgb(0,0,0)">
General changes in the JDK usually address specific problems without introducing the aforementioned risk or complexity. That's why you see JDK guide usually recommend starting with test coverage addition or simple bug fixes. And that is also most of the development
 work in the JDK, even though they don't appear attractive.</div>
<div style="font-family:"Calibri Light","Helvetica Light",sans-serif;font-size:12pt;color:rgb(0,0,0)">
<br>
</div>
<div style="font-family:"Calibri Light","Helvetica Light",sans-serif;font-size:12pt;color:rgb(0,0,0)">
I think if you want a feature, it's better for you to start from the use case - what problem is being addressed by that feature? Are there other solutions, including poor ones or strawman that you can reject to support your proposal? What will happen a decade
 later to this feature? You can try reading through the JEP documents; they usually provide convincing answers to my questions listed ahead.</div>
<div style="font-family:"Calibri Light","Helvetica Light",sans-serif;font-size:12pt;color:rgb(0,0,0)">
<br>
</div>
<div style="font-family:"Calibri Light","Helvetica Light",sans-serif;font-size:12pt;color:rgb(0,0,0)">
Regards,</div>
<div style="font-family:"Calibri Light","Helvetica Light",sans-serif;font-size:12pt;color:rgb(0,0,0)">
Chen Liang</div>
<div style="font-family:"Calibri Light","Helvetica Light",sans-serif;font-size:12pt;color:rgb(0,0,0)">
<br>
</div>
<div id="m_-6008024249066475556appendonsend"></div>
<hr style="display:inline-block;width:98%">
<div id="m_-6008024249066475556divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" style="font-size:11pt" color="#000000"><b>From:</b> amber-dev <<a href="mailto:amber-dev-retn@openjdk.org" target="_blank">amber-dev-retn@openjdk.org</a>> on behalf of Attila Kelemen <<a href="mailto:attila.kelemen85@gmail.com" target="_blank">attila.kelemen85@gmail.com</a>><br>
<b>Sent:</b> Saturday, January 24, 2026 8:47 AM<br>
<b>To:</b> Archie Cobbs <<a href="mailto:archie.cobbs@gmail.com" target="_blank">archie.cobbs@gmail.com</a>><br>
<b>Cc:</b> Amazing Code <<a href="mailto:amazingcodewithus@gmail.com" target="_blank">amazingcodewithus@gmail.com</a>>; <a href="mailto:amber-dev@openjdk.org" target="_blank">amber-dev@openjdk.org</a> <<a href="mailto:amber-dev@openjdk.org" target="_blank">amber-dev@openjdk.org</a>><br>
<b>Subject:</b> Re: Incident Report 9079511: Java Language Enhancement: Disallow access to static members via object references</font>
<div> </div>
</div>
<div>
<div dir="ltr">Oh, wow. I did vaguely recall mentioning this missing feature. Apparently, it was on a thread you started: <a href="https://mail.openjdk.org/pipermail/compiler-dev/2023-October/024417.html" target="_blank">https://mail.openjdk.org/pipermail/compiler-dev/2023-October/024417.html</a>
<div><br>
<div>Well, thank you, I guess. I should maybe contribute instead of just complaining, and things might happen earlier :). I'm just not so great with long bureaucratic processes, and generally lost how to start if I believe a feature (even if small) should be
 implemented in the JDK (or related tools). That is, my general expectation would be that if I just send a PR, then it would be ignored and lost within the many things of the JDK (at least as far as I have seen, actually implementing it is usually secondary
 to having it discussed with relevant people).</div>
</div>
</div>
<br>
<div>
<div dir="ltr">Archie Cobbs <<a href="mailto:archie.cobbs@gmail.com" target="_blank">archie.cobbs@gmail.com</a>> ezt írta (időpont: 2026. jan. 24., Szo, 15:08):<br>
</div>
<blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div dir="ltr">
<div>Funny you should mention that... :)</div>
<div><br>
</div>
<div>In JDK 26+ you will be able to do this via flags like <span style="font-family:monospace">-Werror:static</span></div>
<div><br>
</div>
<div>See <a href="https://bugs.openjdk.org/browse/JDK-8349847" target="_blank">https://bugs.openjdk.org/browse/JDK-8349847</a> for details.</div>
<div><br>
</div>
<div>-Archie</div>
<br>
<div>
<div dir="ltr">On Sat, Jan 24, 2026 at 7:08 AM Attila Kelemen <<a href="mailto:attila.kelemen85@gmail.com" target="_blank">attila.kelemen85@gmail.com</a>> wrote:<br>
</div>
<blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div dir="ltr">
<div>
<blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div dir="ltr">
<div dir="ltr">
<div>My $0.02: This is an easy call. The answer is that it's not worth changing because (b) this would cause legacy to to start failing to compile, which is violates Java's stellar reputation for backward compatibility, and (b) there is already a perfectly
 reasonable workaround, i.e. <span style="font-family:monospace">-Xlint:static -Werror</span><span style="font-family:arial,sans-serif">.</span></div>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>I'm not arguing that the original request should be implemented and break existing code (bad as they are). However, this suggestion doesn't really work, because javac doesn't support different sets of values for `Werror` and for mere warnings. That is,
 I usually want to turn on almost everything for `Xlint` , but I definitely don't want every warning to be an error (most notably, I don't want `@deprecated` to immediately fail compilation, but I want it to be reported as a warning).</div>
</div>
</div>
</blockquote>
</div>
<div><br clear="all">
</div>
<br>
<span>-- </span><br>
<div dir="ltr">Archie L. Cobbs<br>
</div>
</div>
</blockquote>
</div>
</div>
</div>

</div></blockquote></div>