<div dir="ltr"><div>As Archie mentioned, this is already possible in JDK 26 by selectively enabling some lint warnings as errors with `-Werror`. Not sure what more a javac plugin could do.</div><div><br></div><div>As for having better toolings: This is the wrong list to request that. Those requests should go to the appropriate tool provider. Though as for Maven/Gradle plugins: There are already plenty of static analyzers and they usually can be configured to fail on various problems. A lot more than just "static" (in fact, there are a lot of far worse things you can do than calling static members on an object). I would recommend using these static analyzers until you can move to JDK 26+ (or if your favorite one doesn't support selective errors, then ask them for such a feature).</div><div><br></div><div>Also, I don't see the "static" problem to be so extreme as to warrant a campaign on its own (especially not from the JDK team). They are bad, but if this is the biggest issue on projects you are working on, then I honestly envy you :)</div><div><br></div><div>Attila</div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">Amazing Code <<a href="mailto:amazingcodewithus@gmail.com">amazingcodewithus@gmail.com</a>> ezt írta (időpont: 2026. jan. 26., H, 4:38):<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 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</div>
</blockquote></div></div>