<div dir="auto"><br><div dir="auto"><br></div><div dir="auto">The new features for compact source files and instance main methods are about to make their GA debut in JDK 25:</div><div dir="auto"><br></div><div dir="auto"><a href="https://openjdk.org/jeps/8344699">https://openjdk.org/jeps/8344699</a></div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">Regarding the decision not to implicitly import static methods inside <a href="http://java.io">java.io</a>, 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 <a href="http://java.io">java.io</a> for compact source files only).</div><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><div dir="auto"><br></div><div dir="auto">Is there any chance we might see something like this in the future?</div><div dir="auto"><br></div><div dir="auto">- Always yours. </div><div dir="auto"><br></div></div>