Signature.TypeArg to change to algebraic type

[-]

Thanks for your suggestions, Brian. I have created a patch at
https://github.com/openjdk/jdk/pull/16517 for preliminary reviews. The 2
usage updates in remapper and javap are good examples of how the new
user code will look like.

One minor detail I wish to discuss: should we rename
WildcardIndicator.DEFAULT to NONE? To be closer to the representation in
JVMS.

Another remark: I initially wanted to additionally expose signatureString()
for TypeArg, but after more thinking, I believe the merit of
ClassSignature, MethodSignature, and Signature having signatureString() is
due to them being directly usable within Signature attributes. In contrast,
there's no case in which a TypeArg is used alone. And the single
signatureString() method usage in the implementation was updated in favor
of a switch.


On Sun, Nov 5, 2023 at 6:35 AM Brian Goetz <brian.goetz at oracle.com> wrote:

>
>
> > Thus, I believe the impact is on the lesser end. Before we perform the
> > refactor, should we handle default, extends, super in one class +
> > 3-value enum or 3 classes (like RuntimeInvisible/Visible annotations)?
>
> I think the enum approach is probably better suited to this situations.
> We have separate R{VI}AA classes because we decided "every attribute
> defined in the JVMS should have its own attribute subtype" (and similar
> with each kind of classfile metadata), but for something as simple as
> this an enum for variance seems more properly sized.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/classfile-api-dev/attachments/20231106/2ffc958c/attachment.htm>