<div dir="ltr"><div>Hei Chen,</div><div><br></div><div>I would argue that code attributes are the most common type of custom attributes, as attributes on other elements often can be expressed by annotations. Even  compilers for other languages on the JVM use annotations where they can as of today. While code (type) annotations are supported, many code attributes try to mark a segment of byte code, whereas code annotations target a specific instruction. This is what makes them so common. As a matter of fact, I thought about this recently, that Java could likely make the need for custom code attributes obsolete if one could annotate blocks of code such as in: @MyAnnotation { ... }, but of course this is not an option today, and custom attributes will not disappear even if this option was supported by the class file format.<br></div><div><br></div><div>With this background, almost all custom attributes I  ever encountered  were code attributes that mark segments of code. Without an option to resolve a bci to a label and vice versa, I already see a range of byte code power users which will struggle to take the Class File API into use. At the same time: ASM's supports this, but the API is complicated, so there is also a good opportunity to offer a better user experience, if done right.</div><div><br></div><div>This is why I was hoping that bci could be avoided in the public API to begin with. I already see some needed deprecation if one would needs to adjust this later.</div><div><br></div><div>Thanks, Rafael<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Am Mo., 11. Nov. 2024 um 00:28 Uhr schrieb Chen Liang <<a href="mailto:chen.l.liang@oracle.com">chen.l.liang@oracle.com</a>>:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="msg-503750615108289631">




<div dir="ltr">
<div style="font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
Hi Rafael,</div>
<div style="font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
You are correct.  I had previously created an issue <a href="https://bugs.openjdk.org/browse/JDK-8341274" target="_blank">
https://bugs.openjdk.org/browse/JDK-8341274</a> to track this demand.  Since this scenario has no way to bypass, maybe we can raise this issue to P3 and work on this feature for JDK 24.  Also I wonder how frequently are custom attributes storing BCIs?</div>
<div style="font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
<br>
</div>
<div style="font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
For LineNumberInfo: I believe the Label-based version, LineNumber, is already streamed in class file reading, and can be sent to the builder also via CodeBuilder::lineNumber(int).  Your particular use case can probably be covered by the RFE too, once we can
 convert labels to BCIs in non-Code attributes.</div>
<div style="font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
<br>
</div>
<div style="font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
Regards,</div>
<div style="font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
Chen Liang</div>
<div id="m_-503750615108289631appendonsend"></div>
<hr style="display:inline-block;width:98%">
<div id="m_-503750615108289631divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" style="font-size:11pt" color="#000000"><b>From:</b> classfile-api-dev <<a href="mailto:classfile-api-dev-retn@openjdk.org" target="_blank">classfile-api-dev-retn@openjdk.org</a>> on behalf of Rafael Winterhalter <<a href="mailto:rafael.wth@gmail.com" target="_blank">rafael.wth@gmail.com</a>><br>
<b>Sent:</b> Saturday, November 9, 2024 2:32 AM<br>
<b>To:</b> classfile-api-dev <<a href="mailto:classfile-api-dev@openjdk.org" target="_blank">classfile-api-dev@openjdk.org</a>><br>
<b>Subject:</b> Mapping byte code offsets in custom code attributes</font>
<div> </div>
</div>
<div>
<div dir="ltr">
<div>Hello,</div>
<div><br>
</div>
<div>I mentioned before that I think there is still a missing bit when it comes to custom code attributes, and mapping them using an AttributeMapper. Many code attributes point to a location, or area, within a method. This typically implies specifying one or
 two byte code offsets within an attribute.</div>
<div><br>
</div>
<div>To implement this, I would need a possibility to translate offsets to labels within an attribute mapper, and vice versa. For example, if I created byte code from a different source, where a method consists of multiple files, I would want to mark what part
 of the method comes from what file.</div>
<div><br>
</div>
<div>I do not currently know of a way to do this in the Class File API. To resolve this, I would have hoped that the attribute reader method would be able to issue labels that are later issued when the code instructions are supplied. Similarly, I would have
 hoped that the attribute writer method would be capable of translating labels to byte code offsets.</div>
<div><br>
</div>
<div>In the same way, I would have hoped that all attributes such as LineNumberInfo of the LineNumberTableAttribute would expose bytecode offsets as labels and not as integers, as the latter does not really give any useful information by itself. This way, I
 could also write a custom LineNumberTableAttribute after a method is already created by issuing relevant labels, but by only writing the attribute when the entire method was visited. Sometimes this is necessary when generating code, when the information about
 the actual line numbers is only retrieved at a later stage that requires knowledge of the entire method.</div>
<div><br>
</div>
<div>As I understand it, the ClassFile API is supposed to be released in Java 24. Are there still plans to integrate such a change? After that it would require incompatible changes, therefore I had hoped this would make it into the final version.</div>
<div><br>
</div>
<div>Thanks! Rafael<br>
</div>
</div>
</div>
</div>

</div></blockquote></div>