Class & interface terminology

Alex Buckley alex.buckley at
Thu May 7 23:19:19 UTC 2020

On 5/7/2020 3:24 PM, Dan Smith wrote:
> Are you comfortable with the tension between "annotation interface
> declaration" and "enum declaration", or do we need to keep pulling on
> the string to get "enum class declaration"?

As weird as "annotation interface declaration" is, there has to be some 
word between "annotation" and "declaration", and if we're throwing out 
types and bringing in classes and interfaces, then "annotation 
type^H^H^H^Hinterface declaration" is the answer, that's it, nothing 
more to say. "enum declaration" OTOH doesn't need anything inserted.

> (One argument for being okay with some incongruousness here: enum
> declarations literally say 'enum' in their syntax. Annotation
> [interface] declarations do not say 'annotation'—instead, they say
> 'interface'.)

If you pronounce `@` as "annotation", then `@interface Foo {..}` is an 
annotation interface declaration (of Foo) just as congruously as `enum 
Color {..}` is an enum declaration (of Color).

>> In that vein: If there are class and interface types for variables,
>> then there are also annotation types for variables -- `Foo x =
>> blah.getDeclarationAnnotation(Foo.class)` is legal, and lets you
>> call Foo's methods on `x` in order to retrieve element values. So:
>> Annotation: @Foo Annotation interface: Foo, with elements name and
>> age Annotation interface declaration: @interface Foo { String
>> name(); int age(); } Annotation type: Foo, as in the static type of
>> a variable declared as `Foo x;`
>> Also, there are enum types -- in `Color c = Color.RED;`, the first
>> Color is an enum type and the second Color is an enum class, right?
>> That's the kind of discussion I'm hoping for in the spec draft's
>> intro, expanding on the mysterious clause "A class type or an
>> interface type is variable or expression type".
> Sure, I can expand on that some.
> "Annotation type" and "enum type" have reasonable interpretations,
> but you'd rarely actually want to use those terms, because these are
> just special cases of "interface type" and "class type". One of the
> big reasons for emphasizing that an [enum/enum type/enum class] *is
> a* class is so that it's clear that everything we say about class
> types includes enum types.

I agree that in a top-down discussion, you wouldn't need to say 
"annotation type" or "enum type" very often ... but in a bottom-up 
discussion about the meaning of some source code, you'd want to say 
"`col` has an enum type, and we switch over it here, RED, GREEN, BLUE 
..." rather than "`col` has a class type".

We ought to be able to represent the taxonomy in a table, where any 
combination of row title and column title gives something meaningful:

           <No qualifier> | Declaration     |  Type
Class     C              | class C {..}    | C in `C c;`
           C              | class C<T> {..} | C<String> in `C<String> c;`

Enum      Color          | enum Color {..} | Color in `Color c;`
Record    Point          | record Point... | Point in `Point p;`
Interface   I
Annotation  Foo

Please incorporate a table like this in the intro. Maybe the table above 
is no good because it never admits "enum class" or "annotation 
interface". 30 pages of detailed JLS changes look impressive but all 
they do is embody a taxonomy that should be explainable to every Java 
programmer in under 30 lines.

(In exchange, I will provide the ASCII art for 
toplevel/nested/member/local/anonymous classes!)


More information about the amber-spec-experts mailing list