We could, of course, prevent class access from outside the class
too, effectively making such classes visible only to the
launcher. But this would come at no small cost to prevent such
accesses, and for limited benefit.
We can cheaply disallow access by
- only allowing one compilation unit if there is an unnamed class.
- mark the generated class as synthetic (see JVMS 4.7.8) so it does
not work with separate compilation.
Yes, but this has several disadvantages.
- More complicated translation schemes mean more speed bumps merging
onto the highway;
- It is a more limited programming model, users can't even use records
unless they are local.
The status-quo proposal currently says: the name of the class is
not visible from within the class, you can't have constructors or
instance initializers, you get an implicit no-arg constructor like
every other constructor-less class. If you want a more complex
construction protocol, or supertypes, or class declaration
annotations, or to live in a package, declare a class. This still
seems pretty OK.
I still think that allowing fields inside an unamed class is a mistake
(if we can avoid to talk about null at the beginning, it's a win).
I understand why this is appealing to you, but again, it smacks of
trying to engineer a "beginner-safe programming model subset", which I
think is a fool's game here. The goal is to match the ceremony overhead
to what the user actually uses. Requiring a class declaration in order
to declare a superclass makes sense -- because this is where a class
declaration adds value -- but "no fields" seems more of a gratuitous,
paternalistic restriction. It also restricts the programming model in
ways that rule out pedagogically useful intermediate refactorings, even
if they are not a stable endpoint.
