<!DOCTYPE html><html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body>
    <font size="4" face="monospace">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.  <br>
      <br>
      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.<br>
    </font><br>
    <div class="moz-cite-prefix">On 1/23/2026 7:56 AM, Tagir Valeev
      wrote:<br>
    </div>
    <blockquote type="cite" cite="mid:CAE+3fjZhKF9Z0XDTniB+dwuu4WZ=rEhO-fAmdWrPqXbOqQD-cg@mail.gmail.com">
      
      <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 gmail_quote_container">
        <div dir="ltr" class="gmail_attr">On Fri, Jan 23, 2026 at
          1:43 PM Amazing Code <<a href="mailto:amazingcodewithus@gmail.com" moz-do-not-send="true" class="moz-txt-link-freetext">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 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>
    <br>
  </body>
</html>