Towards cleaner nesting

Brian Goetz brian.goetz at
Fri Jan 10 21:43:40 UTC 2020

>>> - interfaces can't directly contain instance initializers/constructors, instance/local variables, or inner classes (maybe)
>> In order to have inner classes in an interface, we'd have to have a non-static modifier, since nested classes in interfaces are allowed now and are implicitly static.
> Yep. But letting syntax drive this decision doesn't seem very much in the spirit of "anything can be nested in anything", so maybe new syntax is worth it to iron out this wrinkle? Or not—maybe "no new syntax" is where we draw the line.

It's not just syntax; it's not clear to me whether inner classes of 
interfaces make enough sense / have enough applicability to warrant such 
a change.  My thinking was to smooth out the gratuitous restrictions 
within the model we have, and clean up the language in the spec, and 
then think about whether there's more to do.
>>> - annotation types can't directly contain things prohibited in interfaces, or instance/local methods (maybe)
>>   - currently annos cannot have fields, default methods, or static methods -- this still seems a reasonable restriction.
> Why? I mean, I don't really care all that much, but if we're removing ad hoc restrictions, this one (no methods) certainly seems ad hoc. We don't even need new syntax.

Because annotations are supposed to be pure metadata.  These things all 
pull state and behavior into something that is supposed to be pure 
metadata.   I mean, sure, I can imagine a world that blurs the 
distinction between annotations and interfaces, but I'm not seeing these 
restrictions as _gratuitous_; they were made deliberately.

More information about the amber-spec-experts mailing list