RFR: 8294982: Implementation of Classfile API [v12]

[Maurizio Cimadamore]

On Mon, 6 Feb 2023 14:32:12 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/classfile/ClassSignature.java line 34:
>> 
>>> 32:  * Models the generic signature of a class file, as defined by JVMS 4.7.9.
>>> 33:  */
>>> 34: public sealed interface ClassSignature
>> 
>> It is a bit odd to have Signature and XYZSignature in the API with the latter not extending the former. I think I get what the API is aiming for though - e.g. Signature is for modelling low-level "portions" of the signature attributes, whereas ClassSignature, MethodSignature and friends are there to model the signature attribute attached to a class, method, etc.
>
> The confusion come from simplified name. Signature probably should be called JavaTypeSignature according to the spec. ClassSignature and MethodSignature could not extend it, as it would not respect the reality. Each of them are completely different species. Signature (or JavaTypeSignature) on the other side has many sub-types.

I think you mean `TypeSignature` from JLS 4.3.4 ? If so, I get it. To me it looks as if "Signature" really means "TypeSignature" - then it would make sense as to why `MethodSignature::arguments` returns a `List<Signature>` (e.g. because it should be `List<TypeSignature>`, as in the spec).

Also, from a modelling perspective, I see other problems too - in the JVMS, type signatures are defined as follows:


TypeSignature:
    FieldTypeSignature
    BaseType
```    
And:


FieldTypeSignature:
    ClassTypeSignature
    ArrayTypeSignature
    TypeVariableSignature 


So I'd roughly expect a type with 4 subclasses (type, then class <: type, array <: type, tvar <: type).

But the Signature class currently has other subclasses too - such as `ThrowableSig` - which is really only an (optional) part of method signatures. And, similarly, it also has `TypeParam`, which is a part of method/class signature - but is _not_ a type signature per se.

Summing up, it seems to me that the naming issue (which is not that important) hides a bigger modelling issue.

-------------

PR: https://git.openjdk.org/jdk/pull/10982