Lifting the restriction on the number of public classes per file
John Rose
john.r.rose at oracle.com
Tue Nov 27 02:04:01 UTC 2018
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>
More information about the amber-spec-experts
mailing list