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.
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). 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 :) Attila Amazing Code <[email protected]> ezt írta (időpont: 2026. jan. 26., H, 4:38): > Hello all, > > 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 > *option > *to enforce instance-qualified static access as a hard rule, while > preserving backward compatibility for everyone else. > > *Proposal (summary)* > Provide an opt-in enforcement stack consisting of: > 1. A reference *javac plugin* (e.g. StaticAccessEnforcer) that fails > compilation on instance-qualified static accesses when enabled; > 2. companion *Maven/Gradle plugins* that automatically enable the > plugin for projects that add the dependency or set a property; > 3. *IDE quick-fixers* and a command-line *codemod* to assist automated > migration; and > 4. when/if available, recommend using per-category Werror (e.g. > `-Werror:static`) for CI once OpenJDK supports it broadly. > > *Why this approach?* > - *No language break* — default javac behavior remains unchanged. > - *Opt-in* — new projects or teams can opt to treat the warning as an > error by adding a dependency/flag. > - *Ecosystem friendly* — leverages javac plugin SPI, Checker > Framework/ErrorProne patterns, and IDE support. > :contentReference[oaicite:11]{index=11} > > *Implementation sketch* > - 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} > - Provide a `static-access-enforcer` Gradle/Maven plugin that wires the > `-Xplugin` or annotation processor automatically. > - Include automated codemod tooling (JavaParser/Eclipse JDT) and an > IntelliJ quick-fix to perform safe replacements. > - Plugin modes: `report` / `warn` / `error`, and support > `@SuppressWarnings("static")` or per-file exclusion. > > *Request* > If this sounds reasonable, I can prepare: > - a small reference implementation (javac plugin + sample Maven config), > and > - a short JEP-style note describing migration story and sample fixes. > > Thank you for considering this compromise — it preserves Java’s > compatibility guarantees while giving teams a practical path to stronger, > enforced conventions. > > Kind regards, > Kamlesh >
