Possible future implicit import of static methods

[mirage]

It's fair.

Thank you for the explanation.

My best wishes for you and all other developers working on the evolution of
the Java platform.

El mar, 4 de mar de 2025, 9:16 a. m., Brian Goetz <brian.goetz at oracle.com>
escribió:

> 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.
>
> 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.
>
> 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.
>
> 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.
>
> So we are actually feeling quite good about the conclusion of "nothing is
> auto-static-imported".
>
>
>
>
>
> On 3/3/2025 9:14 PM, mirage wrote:
>
>
> 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.
>
> 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.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20250304/82caeef9/attachment.htm>