<p dir="ltr">It's fair.</p>
<p dir="ltr">Thank you for the explanation.</p>
<p dir="ltr">My best wishes for you and all other developers working on the evolution of the Java platform.</p>
<br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">El mar, 4 de mar de 2025, 9:16 a. m., Brian Goetz <<a href="mailto:brian.goetz@oracle.com">brian.goetz@oracle.com</a>> escribió:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><u></u>

  
  <div>
    <font size="4" face="monospace">The question of automatically
      statically importing certain "important" methods was a fraught
      one, and the more we investigated it, the more we regretted
      opening this particular Pandora's Box.  <br>
      <br>
      The reality is that any method that is static-imported by the
      language, effectively is elevated to a "language feature", just
      one with a regularized syntax.  And this is a pretty high bar.  We
      started with `println`, which almost everyone thought "obviously"
      was important enough to be important enough to clear that bar. 
      But once we started investigating, the "next most important"
      method could barely jump 10% as high as println did, and it went
      downhill from there.  Indeed, it seems we were mostly trying to
      extrapolate from a single example.  <br>
      <br>
      As part of the exploration, we looked at the set of "built in"
      functions in other languages, such as Python, and asked ourselves:
      "would we be proud of this set of built-in functions."  And the
      answer was that it was really kind of an accidental grab bag, and
      we surely didn't want that -- and we couldn't imagine how we
      wouldn't end up with that.  <br>
      <br>
      The inevitable bikeshedding of "please elevate my favorite method"
      would indeed be a ongoing, contentious-at-times, expensive
      process.  But that's not even the worst part -- we would surely
      end up with yet another accidental grab bag, which does not help
      users form a coherent mental model of these specially-treated
      functions.  <br>
      <br>
      So we are actually feeling quite good about the conclusion of
      "nothing is auto-static-imported".  <br>
      <br>
      <br>
      <br>
      <br>
    </font><br>
    <div>On 3/3/2025 9:14 PM, mirage wrote:<br>
    </div>
    <blockquote type="cite">
      <div dir="auto"><br>
      </div>
      <div dir="auto">Still, I believe it would be worth
        considering—perhaps in a future JEP—the implicit import of some
        of the most commonly used static methods in java.lang (maybe
        including IO, Math, and utility methods in wrapper classes), not
        just for compact source files but for all file types. I’ve
        always found it odd to limit such improvements to “classless
        main files” or files with an implicit class declaration. Many
        utility methods in java.lang are so fundamental and universally
        used that it’s unlikely anyone would bring in a third-party
        library just to parse a string to a numeric value or vice versa.
        Therefore, the rationale for requiring explicit class
        declarations (to identify the source of these methods and
        distinguish between similarly named methods in different
        classes) doesn’t seem very compelling in these basic cases.
        Removing the implicit static import from this JEP leaves the
        door open for a future JEP to go further.</div>
      <div dir="auto"><br>
      </div>
      <div dir="auto">I realize the main challenge is deciding which
        static methods deserve this special treatment (and there will
        always be people advocating for their personal favorites).
        However, these methods could be introduced gradually, and the
        implicit import wouldn’t break source compatibility.</div>
    </blockquote>
    <br>
  </div>

</blockquote></div>