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

[Amazing Code]

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

On Sun, 25 Jan 2026 at 11:04, Chen Liang <chen.l.liang at oracle.com> wrote:

> 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)
>
> > how to start if I believe a feature (even if small) should be
> implemented in the JDK (or related tools).
>
> 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.
>
> 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.
>
> 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.
>
> Regards,
> Chen Liang
>
> ------------------------------
> *From:* amber-dev <amber-dev-retn at openjdk.org> on behalf of Attila
> Kelemen <attila.kelemen85 at gmail.com>
> *Sent:* Saturday, January 24, 2026 8:47 AM
> *To:* Archie Cobbs <archie.cobbs at gmail.com>
> *Cc:* Amazing Code <amazingcodewithus at gmail.com>; amber-dev at openjdk.org <
> amber-dev at openjdk.org>
> *Subject:* Re: Incident Report 9079511: Java Language Enhancement:
> Disallow access to static members via object references
>
> Oh, wow. I did vaguely recall mentioning this missing feature. Apparently,
> it was on a thread you started:
> https://mail.openjdk.org/pipermail/compiler-dev/2023-October/024417.html
>
> 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).
>
> Archie Cobbs <archie.cobbs at gmail.com> ezt írta (időpont: 2026. jan. 24.,
> Szo, 15:08):
>
> Funny you should mention that... :)
>
> In JDK 26+ you will be able to do this via flags like -Werror:static
>
> See https://bugs.openjdk.org/browse/JDK-8349847 for details.
>
> -Archie
>
> On Sat, Jan 24, 2026 at 7:08 AM Attila Kelemen <attila.kelemen85 at gmail.com>
> wrote:
>
> 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. -Xlint:static
> -Werror.
>
>
> 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).
>
>
>
> --
> Archie L. Cobbs
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20260126/92f5c475/attachment.htm>