On Thu, 9 Feb 2023 12:45:27 GMT, Maurizio Cimadamore <mcimadam...@openjdk.org> wrote:
>> 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. No problem, I had to remind myself all the reasons why does it look like Rubik's cube :) ------------- PR: https://git.openjdk.org/jdk/pull/10982
