RFR: 8294982: Implementation of Classfile API [v12]

[Maurizio Cimadamore]

On Tue, 7 Feb 2023 14:51:06 GMT, Adam Sotona <asotona at 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