Incident Report 9079511: Java Language Enhancement: Disallow access to static members via object references

[Attila Kelemen]

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 <amazingcodewithus at gmail.com> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20260126/5f402ccf/attachment.htm>