Class & interface terminology

[forax at univ-mlv.fr]

----- 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é: Vendredi 8 Mai 2020 01:11:48
> Objet: Re: Class & interface terminology

>> 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
> 


Are you trolling me ? If it's a kind of joke, i don't understand it ?

Yes, the JLS explicily says that an annotation type is an interface so it's a reified type, you can create array of them and declare member types in it (even i never seen a code like that),
all other things are different, it has its own grammar, its own modifiers, no super-type, no overriding, no overloading, no static final/static block, etc 

Chapter 9 of the spec defines interface and Annotation are in chapter 9.6,
but all the sub-sections of 9.6 explain why the previous sections (9.1 to 9.5) are not valid for an annotation type

9.1  annotation types has its own grammar and its own modifier 
9.1.3 and 9.2: annotation types use delegation not inheritance (apart java.lang.Annotation) so all inheritance of members doesn't apply
9.3: constant fields: doesn't apply
9.4: method, overloading, overriding: doesn't apply
9.5: member type: partially applicable, you can put an interface inside an annotation but again 9.6 override this section with the rule about the simple name of an annotation

So to summarize, an annotation type is like an interface apart the fact that almost all the rules don't apply.


> 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

super-interfaces, an annotation type can not have super interfaces ??

> https://docs.oracle.com/javase/specs/jls/se14/html/jls-4.html#jls-4.3

it's about annotation declared on type, it's not about the annotation type, so not relevant

> https://docs.oracle.com/javase/specs/jls/se14/html/jls-4.html#jls-4.7

reified type, yes, an annotation type behave like an interface

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

see above, an annotation has no user-defined super types.

> https://docs.oracle.com/javase/specs/jls/se14/html/jls-4.html#jls-4.10.2

subtyping, again an annotation has no user-defined super types.

> 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.

No, it's not i've said, i have said that:
1/ an annotation is not an interface, an enum is not a class, trying to retrofit them the way you are trying is artificial
2/ "class and/or interface" is not better than "type", i'm sure there is a better term.

Feel free to not answer to that mail if you want to try to prove that i have never read the spec.

Rémi