On Wed, 8 Feb 2023 13:44:13 GMT, Adam Sotona <asot...@openjdk.org> wrote:
>> 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`. I think I also see where the current hierarchy comes from - e.g. while `ThrowableSig` is a part of a method signature, it is indeed used by the production to specify a set of signatures that belong to that set. Thanks for the patience. ------------- PR: https://git.openjdk.org/jdk/pull/10982
