Lifting the restriction on the number of public classes per file

[Liam Miller-Cushon]

On Mon, Nov 26, 2018 at 9:05 PM John Rose <john.r.rose at oracle.com> wrote:

> 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 agree, and would add that making it harder to locate declarations also
affects
humans reading the code, and other tooling besides the compiler and IDEs
(e.g. import and dependency management tools).


> 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?
>

The issue today only exists within package boundaries, and isn't always well
handled (by tooling, or by users' mental models). Making it more common
isn't certain to result in it being better supported and understood.

On Tue, Nov 27, 2018 at 12:47 PM Brian Goetz <brian.goetz at oracle.com> wrote:

> It is an easy rejoinder to say "Then just declare them as nested in the
> Shape, and use static imports to clean up the use-site damage from that."
> But this is a bad answer, because, as Remi and Maurizio point out, this
> affects _the structure of your public API_.  But that means we're putting
> users in a place where they get to pick two of the following three features:
>

Will imports always be necessary when pattern matching on sealed types,
or could there be something like the provision for enum switches?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20181127/26ffe9b4/attachment.html>