Lifting the restriction on the number of public classes per file

[John Rose]

On Nov 26, 2018, at 11:43 AM, Kevin Bourrillion <kevinb at google.com> wrote:
> 
> Multiple top-level classes per file just make code harder to find; what are the advantages?

I suppose the main advantage (as suggested in the examples) would be
flexibility of naming.  With inner classes your names are pkg.NH.{A,B,C…},
where the outer class NH serves as nest host and also scope.  With the
proposal the names could also be pkg.{A,B,C…}, with a common nesthost
(A or NH).

In source code the simple names can be obtained by using an import
which mentions NH:  `` import pkg.NH.* ``.  So there's no great source-level
advantage to having the top-level names (package members) instead
of the nested names (class members).  Maybe there's some advantage
in having reflection avoid mention the "NH$"?

The hardest downside to the proposal is that IDEs and some javac
compilation modes (source-paths) don't know where to look for a file
containing pkg.A, if the classfile pkg/A.class has not yet been generated.

I suppose one answer to that is, "the source path mode doesn't work on
such top-level auxiliary nest membrers".  And IDEs have to sniff at NH.java
a little more carefully to determine if NH.java contains extra definitions.
But these issues already exist and have a user model, right?

On the whole, I don't see a big downside, but neither do I see a killer
use case for pkg.A that isn't covered by pkg.NH.A.

— John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20181126/0bc86649/attachment-0001.html>