<div dir="ltr"><div class="gmail_default" style="font-family:monospace">I completely disagree with this proposal. The warning is good enough. Maybe more attention to the warnings, or better documentation on what they are. It's not super obvious where to find the documentation for them, but Hannes and friends are already working on that.</div><div class="gmail_default" style="font-family:monospace"><br></div><div class="gmail_default" style="font-family:monospace">At best, I might consider turning the warning on by default. But that's about it.</div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Fri, Jan 23, 2026 at 7:57 AM Tagir Valeev <<a href="mailto:amaembo@gmail.com">amaembo@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hello!<div><br></div><div>By the way, this "feature" complicates the static analysis, so I'd like if we get rid of it. There's even a bug in IntelliJ IDEA, which I don't want to fix. Try the following class:<br><br>class Test {<br> static void test() {<br> System.out.println("Static");<br> }<br> <br> static void process(Test test) {<br> test.test();<br> }<br><br> public static void main(String[] args) {<br> process(null);<br> }<br>}</div><div><br></div><div>There's a false-positive warning at `process(null)`: Passing 'null' argument to parameter annotated as @NotNull, despite the code runs perfectly. IntelliJ IDEA assumes that if you dereference the `test` variable via `test.test()` call, then `test` must not be null, so passing `null` to the `process` method should be disallowed. At this stage of analysis, we cannot spend time on resolving the `test()` call and checking whether it's static or not, so we just assume that nobody in their sane mind calls static methods on instance qualifiers.<br><br>By the way, there's a warning already. It's just turned off by default.<br><br>C:\Temp>javac.exe -Xlint:static Test.java<br>Test.java:7: warning: [static] static method should be qualified by type name, Test, instead of by an expression<br> test.test();<br> ^<br>1 warning<br><br>With best regards,</div><div>Tagir Valeev.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Jan 23, 2026 at 1:43 PM Amazing Code <<a href="mailto:amazingcodewithus@gmail.com" target="_blank">amazingcodewithus@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><p>I am writing to propose a language enhancement regarding the handling of static member access in Java.</p><h2><strong>Issue</strong></h2><p>Java currently permits static fields and methods to be accessed through object references, despite static members belonging strictly to the class. This behavior is often misleading and can create confusion, especially in large codebases or among less-experienced developers.</p><p>Example:</p><pre><div><div><div><div></div></div></div><div dir="ltr"><code>MyClass obj = new MyClass();
obj.staticMethod(); // Currently allowed, but confusing
</code></div></div></pre><h2><strong>Proposed Enhancement</strong></h2><p>I request consideration of a change that <strong>disallows access to static members via object references</strong>, enforcing access exclusively through the class name. This would convert the current warning into a <strong>compile-time error</strong>.</p><h2><strong>Rationale</strong></h2><ul><li style="margin-left:15px"><p>Prevents misconceptions about instance vs. class-level behavior</p></li><li style="margin-left:15px"><p>Improves code clarity and consistency</p></li><li style="margin-left:15px"><p>Reduces maintenance complexity in enterprise applications</p></li><li style="margin-left:15px"><p>Encourages best practices already recommended by the community</p></li></ul><h2><strong>Suggested Requirements</strong></h2><ol><li style="margin-left:15px"><p>Compiler should produce an error when static members are accessed through object references.</p></li><li style="margin-left:15px"><p>Error messages should explicitly guide developers to use class-based access.</p></li><li style="margin-left:15px"><p>Rules should apply to static fields, static methods, and static nested types.</p></li><li style="margin-left:15px"><p>Optionally, provide a compiler flag for backward compatibility during migration.</p></li></ol><h2><strong>Conclusion</strong></h2><p>Restricting object-based access to static members would strengthen language clarity and help eliminate a common source of misunderstanding. I kindly request your consideration of this enhancement for future Java releases.</p><p>Thank you for your time and continued work on the Java platform.</p><p>Sincerely,<br><b>Kamlesh Kohli</b></p></div>
</blockquote></div>
</blockquote></div>