Signature model issues

[Adam Sotona]

From: classfile-api-dev <classfile-api-dev-retn at openjdk.org> on behalf of liangchenblue at gmail.com <liangchenblue at gmail.com>
Date: Wednesday, 1 March 2023 22:03
To: classfile-api-dev at openjdk.org <classfile-api-dev at openjdk.org>
Subject: Signature model issues
Hi,
While reviewing the Signature move proposal, I found a few issue with
this model:

1. Signature.TypeArg specifically represents wildcards, which is one
of the type arguments (the other being reference types represented by
Signature.RefTypeSig). Thus, the current model allows passing in a
wildcard as a bound of another wildcard, which is illegal in both the
Java language and JVM.

I see, the wildcards model has been probably simplified and squashed too much.

I recommend renaming Signature.TypeArg to Signature.WildcardSig and
make it directly extend Signature instead (or add another common
superinterface for wildcard and ref type signatures).

Thanks for the proposal, I’ll double-check with all the use cases.
My first impression when looking at Signature.TypeArg now is that it probably should not extend Signature.RefTypeSig nor Signature. It does not represent a signature according to the spec.



2. Another issue with the model is ClassTypeSig does not validate its
input, so it's currently possible to pass a base type or void
signature as a type argument, which is illegal as well, and it won't
cause an error. If we have the common superinterface recommended
above, we can control such malformed inputs.

Right, validation is not there yet. Thanks for pointing it out.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/classfile-api-dev/attachments/20230303/4f3aeb2c/attachment-0001.htm>