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

[Chen Liang]

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<mailto: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<mailto: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/20260125/5ad72428/attachment-0001.htm>