RFR: 8294982: Implementation of Classfile API [v12]

[Adam Sotona]

On Tue, 7 Feb 2023 12:10:43 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

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

Class `Signature` (aka `JavaTypeSignature`), all subclasses, `MethodSignature` and `ClassSignature` are designed according to [JVMS 4.7.9.1 Signatures](https://docs.oracle.com/javase/specs/jvms/se19/html/jvms-4.html#jvms-4.7.9.1)

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

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