Draft JLS spec for records - local types

Brian Goetz brian.goetz at oracle.com
Sun Oct 6 15:06:14 UTC 2019


> When reading the spec, the following caught my attention:
> 
> """A nested record type is implicitly static. It is permitted for the 
> declaration of a nested record type to redundantly specify the static 
> modifier.
> 
>    This implies that it is impossible to declare a record type in the body of 
> an inner class (8.1.3), because an inner class cannot have static members 
> except for constant variables.

Sharp eye!  

Yes, this is sad.  There are three ways to go:

 - Don’t make records implicitly static. 
 - Allow static members in inner classes.
 - Don’t allow records in inner classes, at least for now, and do one of the others later.

I don’t like the first one; inner records violate the spirit of records, which is their entire representation, API, and behavior is derived from their state descriptor.  An inner record would have a hidden extra component, and this would raise uncomfortable questions like “how does it play into the equally calculation.”  Better to say records are what they look like, which makes them implicitly static.  

In the long run, I would like to bust the restriction on inner classes not having static members.  (And similarly, open the door to local enums, local interfaces, etc.)  These fall into the category we’ve been calling “smoother scoping”, which is eliminating some of the ad-hoc nest-x-in-y restrictions.  

It seems the sensible strategy for now is accept the restriction, and fix it as by busting the restriction on inner classes when we can. Its possible we can relax this for records now and general static members later.  

> So in this respect, record type is similar to enum type which is also 
> implicitly static.

Record is similar to enum in many, many ways…

> Although the JLS does not mention explicitly (or at least I can't find it), 
> enum types are not allowed as local types (declared inside methods, 
> constructors or initializers). For example:

Local records should be allowed; we should probably allow local enums at the same time.




More information about the amber-spec-experts mailing list