<div dir="ltr"><div>Thanks for your suggestions, Brian. I have created a patch at <a href="https://github.com/openjdk/jdk/pull/16517" target="_blank">https://github.com/openjdk/jdk/pull/16517</a> for preliminary reviews. The 2 usage updates in remapper and javap are good examples of how the new user code will look like.</div><div><br></div><div>One minor detail I wish to discuss: should we rename WildcardIndicator.DEFAULT to NONE? To be closer to the representation in JVMS.</div><div><br></div><div>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.</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Nov 5, 2023 at 6:35 AM Brian Goetz <<a href="mailto:brian.goetz@oracle.com" target="_blank">brian.goetz@oracle.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
<br>
> Thus, I believe the impact is on the lesser end. Before we perform the <br>
> refactor, should we handle default, extends, super in one class + <br>
> 3-value enum or 3 classes (like RuntimeInvisible/Visible annotations)?<br>
<br>
I think the enum approach is probably better suited to this situations.  <br>
We have separate R{VI}AA classes because we decided "every attribute <br>
defined in the JVMS should have its own attribute subtype" (and similar <br>
with each kind of classfile metadata), but for something as simple as <br>
this an enum for variance seems more properly sized.<br>
</blockquote></div>