Possible future implicit import of static methods

[Brian Goetz]

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/0989cce8/attachment-0001.htm>