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

[J.K.]

Thank you for your reply.

I have a project in Eclipse IDE, where I have various maven dependencies on external DS/ML libraries such as Apache Commons Math, Smile, Tribuo or DJL.
I also have my own classes that add some extra functionality to these external classes.

Then I have multiple classes, programs, with main method that import some of these DS/MLclasses.They are not imported by other classes. These classes with main method read some data, do data cleaning and visualization, ML model training and saving the model. The classes are organized in different packages by problem topic, depending on what problem they analyze or train model for. It seems awkward to give them a class name explicitly since they don't model any business objects to be instantiated. They are just ad hoc programs for analysis, visualization, presentation.

This is my case.

I think other Java users may have similar need to create small Java programs with implicit names and organize them by topic in named packages e.g. reading a CSV file with statistical data and display the data in a chart, reading and processing biological data and printing the result etc.

For example does this class need an explicit name declaration to make the code more readable:

https://github.com/biojava/biojava/blob/master/biojava-core/src/main/java/demo/DemoSixFrameTranslation.java

https://biojava.org/docs/api6.1.0/demo/class-use/DemoSixFrameTranslation.html
Uses of Class
demo.DemoSixFrameTranslation
No usage of demo.DemoSixFrameTranslation

But even for learning purposes. I remember when I was learning Java with IDE, I typically created a project with various packages: lesson1, lesson2 etc. where I put classes with main method where I experimented with different language features. I wanted to have them organized by topic in packages but I didn't instantiate them from other classes.
One of the first thing I learned from the original Sun Java tutorial was, don't use the unnamed package.:-)

Jiri





On Thursday, April 11, 2024 at 02:19:42 PM GMT+2, Ron Pressler <ron.pressler at oracle.com> wrote: 





Thank you for trying out this feature!

Implicit classes are not intended to save the typing effort of writing the line `public class MyClass` but the "conceptual burden" of declaring a class when a class is not needed — there is at most one instance and no other class is interested in your methods. Given that this is what an implicit class expresses, can you explain the situations where you’ve tried to use an implicit class but felt the need to write such a program in a named package?

— Ron

> On 11 Apr 2024, at 09:07, J.K. <netswengineer at yahoo.com> wrote:
> 
> 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