Lifting the restriction on the number of public classes per file
kevinb at google.com
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 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
> *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
More information about the amber-spec-observers