Class & interface terminology

[Dan Smith]

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.