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

[Amazing Code]

Dear all,

Thank you for the thoughtful discussion and for sharing your perspectives
and references.

Based on the feedback, it’s clear that turning instance-qualified static
access into a hard language error is neither justified nor aligned with
Java’s strong backward-compatibility guarantees. The existing mechanisms—
-Xlint:static, IDE inspections, and especially the upcoming selective
-Werror:static support in JDK 26—provide a practical and flexible way for
teams to enforce stricter policies without impacting existing codebases.

I also appreciate the clarification around tooling boundaries and the
reminder that static analysis concerns are best handled by dedicated tools
and IDEs rather than the compiler itself.

Given this, I’m happy to close this proposal here. Thanks again for the
detailed explanations and for taking the time to engage in the
discussion—it was very informative.

Best regards,
Kamlesh

On Mon, 26 Jan 2026 at 15:53, Attila Kelemen <attila.kelemen85 at gmail.com>
wrote:

> 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/40715ce3/attachment-0001.htm>