Possible future implicit import of static methods

[mirage]

The new features for compact source files and instance main methods are
about to make their GA debut in JDK 25:

https://openjdk.org/jeps/8344699

I want to extend my gratitude to all the Java team developers. I’m not a
formal teacher, but I’ve done some minor instructing for students interning
at one of the companies I used to work for. These and other JEPs—such as
import modules and the implicit import of Java.base—certainly bring Java
closer to what new programmers are used to (e.g., Python and JavaScript).
They also allow Java to be more function/method-focused by removing the
need to declare classes when they’re not required, which I personally
believe is a positive direction. I hope Java continues to explore more of
this in the future, but this is just a personal thought.

Regarding the decision not to implicitly import static methods inside
java.io, I know some see this as a misstep. I’ve been following the mailing
discussions about “dot notation” closely, and I personally think
maintaining language consistency is preferable to introducing special-case
features that only work under certain conditions (such as implicit static
imports of java.io for compact source files only).

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.

Is there any chance we might see something like this in the future?

- Always yours.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20250303/8b352313/attachment.htm>