Lifting the restriction on the number of public classes per file

Kevin Bourrillion kevinb at
Mon Nov 26 19:43:37 UTC 2018

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

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

On Mon, Nov 12, 2018 at 8:35 AM Brian Goetz <brian.goetz at> 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 < at>
> *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
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the amber-spec-experts mailing list