Feedback on JEP 463: Implicitly Declared Classes and Instance Main Methods (Second Preview)

J.K. netswengineer at yahoo.com
Thu Apr 11 08:07:46 UTC 2024


Hi,

I would like to give my feedback on:

JEP 463: Implicitly Declared Classes and Instance Main Methods (Second Preview)

JEP draft: Implicitly Declared Classes and Instance Main Methods (Third Preview)

The feedback is from the point of view of Java programmer/developer, not Java spec/JVM expert who knows all the internal Java implementation and restrictions.

My understanding is that this feature is mainly for making learning Java by new programmers easier.

However, I think we live in the computational era when more and more people from other fields not necessarily professional programmers have started using computers to solve their problems. Be it mathematics, natural sciences, medicine, finance, logistics …

On the other hand, professional programmers, like me, have started to write more and more smaller programs in the area of data science (DS) and machine learning (ML).

Both groups of programmers write various smaller programs that import other packages and these programs are not typically imported by other programs so declaring a class name is a redundant ceremony.

Still such programs need to be organized logically and systematically in packages by relevant topics, not all put in one big unnamed package.

For this reason I believe it would be useful to be able to place this kind of programs in named packages.

Rather than relying on a class name chosen by the host system, the name of the class would be the name of the source file with the class as it typically shall be anyway.

The access modifier of such class would be public if any class member is public, otherwise the access modifier would be the implicit package modifier.

Example:

package mypackage;

import org.pkg1.*;
import org.pkg2.*;

void main() {
   DS ML code
}

I think it also fits better into the concept of “Growing a program” gradually:

1.       an implicit class in unnamed package

2.       an implicit class in a named package

3.       an explicit class in a named package, i.e. a class with declared name possibly with modifiers and other class extension or interface implementations

I see a practicality analogy with:

JEP 330: Launch Single-File Source-Code Programs
JEP 458: Launch Multi-File Source-Code Programs
 
JEP 330 was also mainly for learning purpose, but JEP 458 made it more suitable for real world practical use cases.

Thank you for reading my feedback.

Jiri


More information about the amber-dev mailing list