Lifting the restriction on the number of public classes per file

[Kevin Bourrillion]

Sorry for delay. Can we unpack the "for whatever reason" part?  For what
reason?

Unsurprisingly to anyone, we actually hard-ban this practice here. Multiple
top-level classes per file just make code harder to find; what are the
advantages?

On Mon, Nov 12, 2018 at 8:35 AM Brian Goetz <brian.goetz at oracle.com> wrote:

> This was received through amber-spec-comments.
>
> I agree with the general sentiment, especially for sealed types, where we
> want to define an entire sealed type hierarchy in a single compilation unit
> (but for whatever reason, prefer not to nest the subtypes in the super
> type.)  There are some details to be worked out (e.g., use of the
> SourceFile attribute by tools).
>
> Begin forwarded message:
>
> *From: *Francois Green <francois.green at gmail.com>
> *Subject: **Lifting the restriction on the number of public classes per
> file*
> *Date: *November 11, 2018 at 10:09:06 PM GMT+1
> *To: *amber-spec-comments at openjdk.java.net
>
> In the face of the changes in code style that records will bring about, has
> there been renewed discussion about lifting the restriction?
>
>    public interface Blue;
>    public record IKB() implements Blue;
>    public record Azure() implements Blue;
>    public record Royal() implements Blue;
>
> Having to place each line in the code above in its own file seems harsh.
>
>
>

-- 
Kevin Bourrillion | Java Librarian | Google, Inc. | kevinb at google.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20181126/34d38a3d/attachment.html>