Class & interface terminology

[Dan Smith]

> On May 7, 2020, at 4:07 PM, forax at univ-mlv.fr wrote:
> 
> ----- Mail original -----
>> De: "daniel smith" <daniel.smith at oracle.com>
>> À: "Remi Forax" <forax at univ-mlv.fr>
>> Cc: "amber-spec-experts" <amber-spec-experts at openjdk.java.net>
>> Envoyé: Jeudi 7 Mai 2020 23:06:44
>> Objet: Re: Class & interface terminology
> 
>>> On May 7, 2020, at 1:47 PM, Remi Forax <forax at univ-mlv.fr> wrote:
>>> 
>>> 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.
>> 
>> 
>> To contextualize this: you're expressing a narrow concern that "enum" -> "enum
>> class" and "annotation type" -> "annotation interface" may not be appropriate
>> renamings, and that these were (maybe?) intentionally avoided when those
>> features were designed. "Record" -> "record class" would have similar issues.
> 
> No, i disagree about to things
> - trying to tilt each features to be either an interface or an class is not appropriate


>> I disagree with the assertion that an [annotation type/interface] is not an
>> interface. JLS Chapter 9 is quite clear that an [annotation type/interface] is
>> a special kind of interface. Among other things, this means that you're allowed
>> to declare a class that implements an [annotation type/interface].
> 
> Disagreeing by citing one things allowed by both an annotation type and interface is not an argument, it's an anecdote. As i said in my previous mail, the annotation type is a small part of the annotation feature.

So, I was trying to say two things in this paragraph:

1) JLS unambiguously says that an [annotation type/interface] is an interface. There's room for disagreement about whether that's a good design or not, but that is quite clearly what it says.

https://docs.oracle.com/javase/specs/jls/se14/html/jls-9.html
https://docs.oracle.com/javase/specs/jls/se14/html/jls-9.html#jls-9.6

2) That choice makes sense, because there are a lot of rules related to interfaces that apply to [annotation types/interfaces]. I gave you one example, but there are many:

https://docs.oracle.com/javase/specs/jls/se14/html/jls-8.html#jls-8.1.5
https://docs.oracle.com/javase/specs/jls/se14/html/jls-4.html#jls-4.3
https://docs.oracle.com/javase/specs/jls/se14/html/jls-4.html#jls-4.7
https://docs.oracle.com/javase/specs/jls/se14/html/jls-9.html#jls-9.2
https://docs.oracle.com/javase/specs/jls/se14/html/jls-4.html#jls-4.10.2
Etc.

So: you may prefer a model in which classes, interfaces, enums, records, and annotation types are five distinct things. But this is not the model JLS uses, and it would be quite disruptive to refactor in that direction.

A model that might also work: they're all variants of *one* thing. Again, that's a pretty deep change, still would require lots of work to get there. This is, honestly, how we might do it if designing from scratch; we might also avoid separate 'extends' and 'implements' clauses, and for sure we wouldn't have two separate JLS chapters for classes and interfaces.

I'm not saying these are impossible changes. But they are *big* changes.

> - use classes or interfaces as a kind of composed word with the same meaning as "declared type". 
> 
> I don't say that the JLS should not be fixed, as you are showing the is a lot of case where by example, inner class also means local class or declared types shouls also includes type parameters.
> But using "class and/or interface" goes in the opposite direction for me, it's not a specific term.

I've seen different reactions, from "eh, it works" to suggestions for entirely new terms. It definitely makes some people uncomfortable.

I feel strongly that "class or interface" is better than "type", and that we need to stop using "type" in this context. I'm agnostic about what we say instead. But "class or interface" has the benefit that it's already used pretty extensively, which gives it a distinct advantage over most alternatives. Examples:

https://docs.oracle.com/javase/specs/jls/se14/html/jls-1.html#jls-1.3
https://docs.oracle.com/javase/specs/jls/se14/html/jls-4.html#jls-4.3
https://docs.oracle.com/javase/specs/jls/se14/html/jls-5.html#jls-5.1.9
https://docs.oracle.com/javase/specs/jls/se14/html/jls-12.html#jls-12.3
https://docs.oracle.com/javase/specs/jls/se14/html/jls-15.html#jls-15.12.1
Etc.

Or, from JVMS:
https://docs.oracle.com/javase/specs/jvms/se14/html/jvms-2.html#jvms-2.1
https://docs.oracle.com/javase/specs/jvms/se14/html/jvms-2.html#jvms-2.5.5
https://docs.oracle.com/javase/specs/jvms/se14/html/jvms-4.html#jvms-4.4.1
https://docs.oracle.com/javase/specs/jvms/se14/html/jvms-5.html#jvms-5.3
https://docs.oracle.com/javase/specs/jvms/se14/html/jvms-5.html#jvms-5.4.3.1
Etc.

So the way I see it is that we can shift to "class or interface" in the cases that improperly use "type" right now, and if we settle on a single word at some point in the future, we can fix up all of these uses of "class or interface", both old and new.