<div dir="ltr"><div>(I realized that I did not reply-all and wanted to add the mailing list again. Some of the discussion can be found in the quotation below, if anyone is reading.)<br></div><div><br></div><div>I cannot describe a use case that goes beyond mere printing where I could work with BCIs in the context of a Class File API represented list of instructions. If I wanted to create a CharacterRangeTableAttribute, I would always have to resolve BCIs to labels. Why not let the AttributeMapper handle this translation consistently but require BCI as input to the factory method? To me, this seems more error prone and less type-safe.<br></div><div><br></div><div>Maybe I should ask the question differently: what led to a choice of using labels over BCIs when dealing with stack map frames, and for the runtime (in-)visible type annotations? I think the answer is that those are more convenient, despite that they are inlined. I cannot make sense that two groups of attributes are represented in two different ways, when labels are obviously more expressive. I get that type annotations and stack map frames might be more central attributes, where the others are more often used by power users. But also power users would benefit from the better abstraction, so I think this should be the target? If the answer is that there is no time to adjust the API, I wonder if one should avoid exposing those four other attributes until there is time, especially with Java 24 likely being less adopted compared to Java 25 where Oracle plans to offer LTS. I feel like exposing BCIs is premature, if labels could be used, and it would be a shame to lose the opportunity to use labels within these four info attributes. I already see the BCI factories and methods being deprecated in a future release, so why not aim for the best solution already today?<br></div><div><br></div><div>I understand that this API change is out of scope for JDK-8341274, but I would love to see a follow up change that adjusts those four interfaces to use labels and not BCIs, such that the Class File API is consistent. If possible within the release of Java 24, or Java 25 with the BCI methods not exposed before that.<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Am Mo., 11. Nov. 2024 um 16:19 Uhr schrieb Adam Sotona <<a href="mailto:adam.sotona@oracle.com">adam.sotona@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="msg3510438925336967048">





<div lang="EN-US" style="overflow-wrap: break-word;">
<div class="m_3885507924158365885WordSection1">
<p class="MsoNormal"><span style="font-size:11pt">Purpose of </span>JDK-8341274 is to enable labels translation for custom attributes, it means other attributes than LineNumberTable, LocalVariableTable, LocalVariableTypeTable or CharacterRangeTable. It does
 not include any plan to remodel existing architecture.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">What exact use case related to the above-mentioned attributes are you struggling with?<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">Thanks,<u></u><u></u></p>
<p class="MsoNormal">Adam  <span style="font-size:11pt"><u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt"><u></u> <u></u></span></p>
<div id="m_3885507924158365885mail-editor-reference-message-container">
<div>
<div>
<div style="border-width:1pt medium medium;border-style:solid none none;border-color:rgb(181,196,223) currentcolor currentcolor;padding:3pt 0in 0in">
<p class="MsoNormal" style="margin-bottom:12pt"><b><span style="color:black">From:
</span></b><span style="color:black">Rafael Winterhalter <<a href="mailto:rafael.wth@gmail.com" target="_blank">rafael.wth@gmail.com</a>><br>
<b>Date: </b>Monday, 11 November 2024 at 15:44<br>
<b>To: </b>Adam Sotona <<a href="mailto:adam.sotona@oracle.com" target="_blank">adam.sotona@oracle.com</a>><br>
<b>Subject: </b>Re: [External] : Re: Mapping byte code offsets in custom code attributes<u></u><u></u></span></p>
</div>
<div>
<div>
<p class="MsoNormal">Hello,<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">As a goal of this conversation, I was hoping to give feedback on where I see limitations of the current API, something that resulted in JDK-8341274. As I wrote in previous emails on this list, I am evaluating it against a number of use
 cases, all of which use ASM as of today. When I speak of migration, I mean that users of ASM would take the class file API into use instead. This is why I hoped that JDK-8341274 could be concluded by using this API to remodel these four info attributes, to
 be consistent with TypeAnnotation and UninitializedVerificationTypeInfo. Clearly, if those attributes are using labels instead of BCIs, there should be a benefit of using labels exclusively? I had hoped that the Class File API could become as consistent as
 ASM in this regard.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">I also understand that the mentioned info elements are streamlined with the code instruction API. But as the use of code generation has evolved upon ASM over many years, where attributes are not always generated at the same time as the
 attributed code, but later. Rather, one notes down BCIs as labels in the generated code and writes the attribute upon completion. In some cases, such logic can be rewritten to fit the streamlined model. But sometimes this is really hard. Neither the class
 file format, nor the class file API require that attributes on code are created simultaneously, so I was hoping that explicit BCIs could be removed from the public API altogether. Today, they only appear at four locations (LocalVariable, LocalVariableType,
 CharacterRange and LineNumber) throughout the entire Class File API. Anywhere else, BCIs are resolved as labels. I think changing that would add to the Class File APIs quality, consistency and usability, when working with these attributes, similar to how it
 is suggested to work with custom ones. I hoped I could argue that case before the API becomes final and this can no longer be changed.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">Patching line numbers is indeed supported, if one reiterates over the code, but I would not call this a seamless solution in contrast to just writing that attribute after completing the code attribute, if this is what is desired.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">Thanks, Rafael<u></u><u></u></p>
</div>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<div>
<p class="MsoNormal">Am Mo., 11. Nov. 2024 um 14:38 Uhr schrieb Adam Sotona <<a href="mailto:adam.sotona@oracle.com" target="_blank">adam.sotona@oracle.com</a>>:<u></u><u></u></p>
</div>
<blockquote style="border-width:medium medium medium 1pt;border-style:none none none solid;border-color:currentcolor currentcolor currentcolor rgb(204,204,204);padding:0in 0in 0in 6pt;margin-left:4.8pt;margin-right:0in">
<div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:11pt">Hi Rafael,</span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11pt">I’m not sure what is goal of this discussion. Let me answer your questions below.</span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11pt"> </span><u></u><u></u></p>
<div id="m_3885507924158365885m_5231128483693884018mail-editor-reference-message-container">
<div>
<div>
<div style="border-width:1pt medium medium;border-style:solid none none;padding:3pt 0in 0in;border-color:currentcolor">
<p class="MsoNormal" style="margin-bottom:12pt"><b><span style="color:black">From:
</span></b><span style="color:black">Rafael Winterhalter <<a href="mailto:rafael.wth@gmail.com" target="_blank">rafael.wth@gmail.com</a>></span><u></u><u></u></p>
</div>
<div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<div>
<ul type="disc">
<li class="m_3885507924158365885m5231128483693884018msolistparagraph">
What I do not understand is why this model should not be applied for LineNumberInfo, LocalVariableTypeInfo, LocalVariableInfo and CharacterRangeInfo?<u></u><u></u></li></ul>
<p class="MsoNormal"><span style="font-size:11pt"> </span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11pt">LocalVariable, LocalVariableType, CharacterRange and LineNumber are pseudo instructions (code elements). As such they are integral part of the CodeModel
 and they are streamed and transformed with the instructions. </span>LineNumberInfo, LocalVariableTypeInfo, LocalVariableInfo are just inner structure data holders of the corresponding attributes and they serve only to specific use cases requesting the raw
 values.<u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11pt"> </span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11pt"> </span><u></u><u></u></p>
<ul type="disc">
<li class="m_3885507924158365885m5231128483693884018msolistparagraph">
Once a translation mechanism is in place, it should be straightforward to migrate?<u></u><u></u></li></ul>
<p class="MsoNormal"><span style="font-size:11pt"> </span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11pt">I’m not sure what migration do you have in mind.</span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11pt"> </span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11pt"> </span><u></u><u></u></p>
<ul type="disc">
<li class="m_3885507924158365885m5231128483693884018msolistparagraph">
What is the point of offering these attributes in a (public) API then, if not as ready for consumption?<u></u><u></u></li></ul>
<p class="MsoNormal"><span style="font-size:11pt"> </span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11pt">There are regular consumers of the API, like for example javap.</span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11pt"> </span><u></u><u></u></p>
<p class="MsoNormal" style="margin-left:0.5in">
 <u></u><u></u></p>
</div>
<div>
<ul type="disc">
<li class="m_3885507924158365885m5231128483693884018msolistparagraph">
As I see it: Without labels, I would need to implement a custom mapper, for example for writing a custom LineNumberTableAttribute,<u></u><u></u></li></ul>
<p class="MsoNormal"> <u></u><u></u></p>
<p class="MsoNormal">There are two aspects:<u></u><u></u></p>
<ol start="1" type="1">
<li class="m_3885507924158365885m5231128483693884018msolistparagraph">
A custom LineNumberTable attribute mapper overriding the default one is not accepted by the API.<u></u><u></u></li><li class="m_3885507924158365885m5231128483693884018msolistparagraph">
Implementation of a custom attribute similar to LineNumberTable attribute is supported and after JDK-8341274 the support will improve.<u></u><u></u></li></ol>
<p class="MsoNormal"> <u></u><u></u></p>
<p class="MsoNormal"> <u></u><u></u></p>
<ul type="disc">
<li class="m_3885507924158365885m5231128483693884018msolistparagraph">
if I wanted to patch line numbers after creating a method.<u></u><u></u></li></ul>
<p class="MsoNormal"><span style="font-size:11pt"> </span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11pt">Patching line numbers is seamlessly supported. CodeTransform can freely change, add, and remove line numbers.
</span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11pt"> </span><u></u><u></u></p>
</div>
</div>
<p class="MsoNormal"> <u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11pt">From the context I understand you call for indirect translation of each (currently inline) LocalVariable, LocalVariableType, CharacterRange and LineNumber
 into a Label-parametrized pseudo instructions + corresponding LabelTargets. Such model has been rejected in the early Class-File API prototypes for significant negative performance impact.
</span><u></u><u></u></p>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
</div>
</div>
</div>
</div>
</div>
</div>

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