RFR: 8294982: Implementation of Classfile API [v12]

[Adam Sotona]

On Wed, 8 Feb 2023 12:19:35 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>>> `Signature.ThrowableSig` is a `Signature` and it is a common super of `ClassTypeSig` and `TypeVarSig`.
>> 
>> I really don't follow here. ThrowableSig is a piece of a method signature, which starts with "^" and is followed by either a class or a typevar signature. You can never encounter it from the toplevel JavaTypeSignature production. It's ok (as I have said) to have a ThrowableSig element in the API to model the production, but that element should not be a subtype of Signature (at least not if Signature, as you claimed is meant to model the JavaTypeSignature production). That is, there's no "is a" relationship between JavaTypeSignature and ThrowableSig (at least not that I can see when looking at the productions).
>
> OK, I see your point now, I'll fix it.
> Thanks

During the fix I found the definition that `ThrowableSig` (as a super-set of `ClassTypeSig` and `TypeVarSig`) IS `Signature` - that fact is critical for processing.
For example when `MethodSignature` is serialized `ThrowableSig::signatureString` is critical.
Or `ClassRemapper` depends on the inheritence:

signature.throwableSignatures().stream().map(this::mapSignature).toList()

however `mapSignature` could not be applied on `ThrowableSig` when it does not inherit from `Signature`.

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

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