Signature.TypeArg to change to algebraic type

[-]

Currently, TypeArg is only used by 2 consumers: javap and Class-File API's
own Class remapper. This impact should be relatively miniscule.

The creation factories will be updated to return the more specific types;
too. Currently, no producer in the JDK uses those factories except
Class-File API's own parsing.

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)?

On Sat, Nov 4, 2023 at 10:06 PM Brian Goetz <brian.goetz at oracle.com> wrote:

> Makes sense.  Would be good to rough this out to see the impact on the
> codebase?
>
>
>
> On 11/3/2023 9:23 PM, - wrote:
>
> Hello,
> I am currently looking into reimplementing core reflection's signature
> parsing to be based off the new Class-file API.
>
> One thing I noticed when using Signature.TypeArg is that it is a perfect
> candidate for algebraic data type, like:
> TypeArg
>   - Unbounded: a singleton ENUM
>   - Bounded: has 2 fields: 3-way wildcard indicator (+-and none), a
> RefTypeSig
>
> Alternatively, Bounded can be split into 3 classes that each hold a
> RefTypeSig instead of using the 3-way indicator, for the ref type sig is
> not really interchangeable.
>
> This model's main advantage is that users can be assured that they can
> just obtain RefTypeSig if the TypeArg is bounded, without having to write
> dubious Optional.get()/orElseThrow() in user code.
>
> Best,
> Chen Liang
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/classfile-api-dev/attachments/20231104/b783a584/attachment.htm>