On Tue, 7 Feb 2023 14:51:06 GMT, Adam Sotona <asot...@openjdk.org> wrote:
> 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) The production is the same as the one I quoted, but thanks for pointing me at the correct one. So: JavaTypeSignature: ReferenceTypeSignature BaseType and ReferenceTypeSignature: ClassTypeSignature TypeVariableSignature ArrayTypeSignature So, while I can expect that `ArrayTypeSignature` *is a* `Signature` (or `JavaTypeSignature`), I cannot explain why `ThrowsSignature` extends `Signature`. That doesn't seem to follow from the production. That is, if a client obtains a `Signature` and wanted to pattern match, what are the cases it should worry about? I believe the cases are the ones listed above. One thing I missed is that e.g. `TypeParam` is *not* a signature (which is the only case among the nested classes in `Signature`). But `ThrowsSignature`, `TypeArg` and `TypeParam` are signatures even though that doesn't seem to be the case when looking at the production in the JVMS. If we want to keep these fine, but I don't think they should extend `Signature`, either directly or indirectly. That is, `Signature` should be a sealed type with 4 leaves (base-type/array/type var/class-type). ------------- PR: https://git.openjdk.org/jdk/pull/10982
