<div dir="ltr"><div>Question... would it be appropriate for this JEP to mention that support for older-than-current classfile versions is an explicit non-goal?</div><div><br></div><div>Otherwise I think there could be many repeats of <a href="https://mail.openjdk.org/pipermail/core-libs-dev/2024-August/127982.html">this discussion</a> from the other day.<br></div><div><br></div><div>To be clear, I don't disagree with the design choice, I just think it might be worthwhile to address that point directly and clarify the thinking behind it so there's no ambiguity.<br></div><div><br></div><div>As it's written today, a casual reading of the JEP comes across as if we're talking about a great new JDK-sanctioned tool with state of the art design that will help get all of the classfile manipulation libraries on the same page to allow analysis/transformation of any class file on the classpath. Or at least, it doesn't do anything to dispel that notion (unless I'm missing something).<br></div><div><br></div><div>-Archie</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Aug 27, 2024 at 8:58 AM Mark Reinhold <<a href="mailto:mark.reinhold@oracle.com">mark.reinhold@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"><a href="https://openjdk.org/jeps/484" rel="noreferrer" target="_blank">https://openjdk.org/jeps/484</a><br>
<br>
  Summary: Provide a standard API for parsing, generating, and<br>
  transforming Java class files.<br>
<br>
- Mark</blockquote></div><br clear="all"><br><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature">Archie L. Cobbs<br></div>