Class & interface terminology

Alex Buckley alex.buckley at
Thu May 7 21:02:22 UTC 2020

On 5/7/2020 11:48 AM, Dan Smith wrote:
> I'll add that it's useful to think in terms of three different entities:
> 1) Class and interface declarations. These are syntax. Example: "interface List<E> ..."
> 2) Classes and interfaces. These are "symbols". Example: the interface List
> 3) Class and interface types. These are a kind of type. Example: the type List<String>
> There's a one-to-one relationship between class/interface
> declarations and classes/interfaces. There is, in general, a
> one-to-many relationship between classes/interfaces and types. (More
> accurately, types can use classes and interfaces however they like to
> describe sets of values.)
Thank you Dan. The First Edition of the JLS revolved around

   type declarations of class and interface types

because (2) and (3) were the same thing in 1996. Less than 10 years 
later, JSR 14 had introduced a plethora of new terms -- generic types, 
parameterized types, raw types, reifiable types -- which the Third 
Edition of the JLS integrated heroically, but without the exhaustive 
analysis that you have performed here. I look forward to a future JLS 
that revolves around

   class and interface declarations of classes and interfaces.

Speaking of "generic", I would be grateful if you can clarify (maybe 
here, in the first instance, then later in the draft) :

- A generic class or interface declaration begets a generic class or 
interface. (1.1 "Class and interface declarations may be generic" + 8 
"Classes may be generic ...")

- A generic class or interface begets many parameterized class or 
interface types.

- A generic method declaration begets a generic method, which undergoes 
generic method invocation.

It would be good to enhance the introduction of the draft to acknowledge 
the common terms "static type" (perhaps in connection with "A class type 
or an interface type is [a] variable or expression type") and "dynamic 

I confess to similar twitchings as Remi in relation to "annotation 
interfaces". (Not "enum classes", or "record classes" -- all good 
there.) My concern is that 99% of conversations around metadata in Java 
programs are interested in the `@Foo` annotations appearing around their 
source code, not about the Foo annotation interface defined far away by 
someone else. That is, "annotation" usually means "an instance, 
providing literal values for the elements of the annotation interface", 
and not "a declaration of an annotation interface" ... yet the draft has 
"annotation" as "a declaration":

   An annotation declaration specifies a new annotation interface,
   a special kind of interface.

What you're saying here is:  Just like a class declaration introduces a 
class Foo, which `new` turns into an object (an instance of class Foo), 
an annotation declaration introduces an annotation Foo, which `@` turns 
into an object (an instance of annotation Foo).  I always thought of the 
annotation as being `@Foo`, not `Foo`, though I concede that people will 
_say_ "Look at the annotation Foo here, it means ..." while pointing to 
the character sequence `@Foo`.


More information about the amber-spec-experts mailing list