Indeed, this "feature" is a terrible feature. In addition to being
bug-bait, it has interfered with the design of several language
features. It is an example of how trying to be too helpful is actually
unhelpful.
However, the significant part of the request is not "here's a change
that I think is beneficial, that can be evaluated on the merits"; it is
"here is a language change that will break existing programs, that has
to be evaluated on whether the incompatibility is justified." While the
bar for the former is very high, the bar for the latter is
astronomically high.
On 1/23/2026 7:56 AM, Tagir Valeev wrote:
Hello!
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:
class Test {
static void test() {
System.out.println("Static");
}
static void process(Test test) {
test.test();
}
public static void main(String[] args) {
process(null);
}
}
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.
By the way, there's a warning already. It's just turned off by default.
C:\Temp>javac.exe -Xlint:static Test.java
Test.java:7: warning: [static] static method should be qualified by
type name, Test, instead of by an expression
test.test();
^
1 warning
With best regards,
Tagir Valeev.
On Fri, Jan 23, 2026 at 1:43 PM Amazing Code
<[email protected]> wrote:
I am writing to propose a language enhancement regarding the
handling of static member access in Java.
*Issue*
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.
Example:
|MyClass obj = new MyClass(); obj.staticMethod(); // Currently
allowed, but confusing |
*Proposed Enhancement*
I request consideration of a change that *disallows access to
static members via object references*, enforcing access
exclusively through the class name. This would convert the current
warning into a *compile-time error*.
*Rationale*
*
Prevents misconceptions about instance vs. class-level behavior
*
Improves code clarity and consistency
*
Reduces maintenance complexity in enterprise applications
*
Encourages best practices already recommended by the community
*Suggested Requirements*
1.
Compiler should produce an error when static members are
accessed through object references.
2.
Error messages should explicitly guide developers to use
class-based access.
3.
Rules should apply to static fields, static methods, and
static nested types.
4.
Optionally, provide a compiler flag for backward compatibility
during migration.
*Conclusion*
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.
Thank you for your time and continued work on the Java platform.
Sincerely,
*Kamlesh Kohli*
