Class & interface terminology

[Remi Forax]

Plus ça change plus c'est la même chose.

Ok, I will be that angry old man.

There is a good reason why it is done that way, i.e. enum is called enum and not enum class or annotation type is not called annotation interface.
It's to avoid the confusion between the feature of the language and its translation strategy, an annotation type is not an interface, the translation strategy uses an interface (and some attributes), but it's not an interface, an enum is not abstract despite the fact that it can be translated to an abstract class, etc.

This can even be dangerous, if we then want by example introduce a more abstract record that is translated to an interface. The feature is record, not record class, like the feature is enum, not enum class.

Moreover, this has been discussed ad-nauseam during the Java 5 timeframe, i don't see the point to change that now.

Yes it means that "type" is overloaded but it's part of our heritage, yes, this means you have to use static type and dynamic type sometimes where you can use type and class, but i don't see the point to change something that was agreed 20 years ago. In fact, it seems to be the worst time to introduce such change, soon we will introduce reified generics that may force us to redefine the exact relation between a class and a type for the language and the VM so it's wiser to wait until we all have a clear vision of how things work, instead of changing things for the sake of changing them.

Rémi

----- Mail original -----
> De: "daniel smith" <daniel.smith at oracle.com>
> À: "amber-spec-experts" <amber-spec-experts at openjdk.java.net>
> Envoyé: Jeudi 7 Mai 2020 20:48:41
> Objet: Class & interface terminology

> We've made some efforts recently to make more precise usage of the terms
> "class", "interface", and "type". Some impacts:
> 
> - Recent iterations of the records spec include a "Consistent Class and
> Interface Terminology" document which describes changes throughout JLS, mainly
> to reduce improper use of the term "type".
> 
> http://cr.openjdk.java.net/~gbierman/jep384/jep384-20200506/specs/class-terminology-jls.html
> 
> - The "records" feature introduces a special form of classes, "record classes".
> These should not be called "record types". (Similarly, it's "enum classes", not
> "enum types".)
> 
> - The "sealed types" feature is more appropriately described as "sealed classes
> and interfaces", or, abbreviated and less formally, "sealed classes". The JEP
> is being renamed accordingly.
> 
> - The 'PermittedSubtypes' JVM attribute is being renamed 'PermittedSubclasses'.
> 
> Here's the summary from "Consistent Class and Interface Terminology":
> 
>> The following terminology is preferred: a class or interface declaration is a
>> syntactic structure that introduces a class or an interface. Various class and
>> interface declarations have different syntactic forms, and can appear in
>> different contexts, per the grammar. A class type or an interface type is
>> variable or expression type, derived from a class or an interface; these terms
>> should be avoided when talking about the declaration. An enum declaration is a
>> kind of class declaration that introduces a special kind of class, an enum
>> class. An annotation declaration is a kind of interface declaration that
>> introduces a special kind of interface, an annotation interface.
> 
> 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.)
> 
> "Class or interface", rather than "type", is the preferred way to talk about an
> entity in category (2), although it's sometimes okay to abbreviate to "class".
> 
> (The same principles apply in the JVM, although the declaration syntax and type
> system are different than in the Java language.)
> 
> These changes push against some longstanding conventions in the Java community,
> but the over-use of the term "type", and resulting conflation of (2) and (3),
> is an impediment to the progress we're making in the Amber and Valhalla
> projects, so it's helpful to move away from it.
> 
> This isn't a one-time change. I'm sure there's more work to do in JLS and JVMS,
> as the need arises, and various other parts of the ecosystem (reflection APIs,
> javac error messages, javadoc output, JDK code internals, third-party tools,
> etc.) may want to similarly make changes, as needed and practical.