New candidate JEP: 445: Flexible Main Methods and Anonymous Main Classes (Preview)

[Attila Kelemen]

> >2. It would also make writing utility classes easier, thus benefiting
> more people
>
> This is a non-goal, the anonymous main class can only be in the unnamed package of the unnamed module, meaning it is very restricted in use, you can also not reference any method (static or not) of the class from the outside, so it is pretty much impossible to use this feature for utility classes from design.

The fact that the JEP does not declare this as a goal doesn't mean
that it shouldn't be done, and the JEP specifically takes away this
possibility forever. That is, another way which would provide the same
values (and I would argue more) cannot be just swept away by saying
that the original idea didn't declare this as a goal. Even more
specifically, I'm arguing for replacing this JEP with something else,
and I can't argue it in another context, because this JEP would
prevent it from ever happening.

>
> >3. It would allow (assuming the implied class would be visible to
> others) students to first "modularize" their application into separate
> logical units before going to classes.
>
> Again, the class is not visible by design. I also don't understand why it will help modularize, the modularization order should be: "all in main" -> "methods" -> "classes (and friends)" -> "files"
>

Because as is now everything has to be in a single file. Organizing
things into multiple files is a form of modularization, even if on a
very small level, but students should start small.

> If you swap classes and files you ran into a risk of people stop using classes all-together, while stop using files is very unlikely (furthermore, it is ordered by size)
>
> >4. It would not require touching the "main" finding logic. That could
> be considered separately in another JEP.
>
> But the static solution would require new semantics and an unnamed class, which are arguably as big of a language feature

What are the default modifiers is already context dependent. It
wouldn't be such a new concept, and the current proposal is already a
big language feature of which this would be just one of its
properties. Compared to imagining it inside an anonymous class it is
less in my opinion.