On Wed, 8 Feb 2023 12:19:35 GMT, Adam Sotona <asot...@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
