<div dir="ltr">Chen, <div><br></div><div>(Continued... 🙂 )</div><div><br></div><div>To follow your explanation I found and examined the internal <i>AbstractMemorySegmentImpl.java</i> and it makes sense that <i>layout.varHandle().set((MS)this, ...) </i>would throw IAE, because MS is an argument.  And, there is no way that the varHandle knows that it is being called by a set(...) method of MS instead of a user, for example.  </div><div><br></div><div>From a normal user of the public API, this is pretty subtle because the MS::set(...) method appears to operate on the MS.  </div><div><br></div><div>Originally, to understand this change of the type of exception I tried to look through the release notes, but I guess what you are telling me is that release notes would not necessarily include changes from preview code; that is unfortunate.  Even the title of the Bug report you sent me is a bit removed from my case here, and it is unlikely that I would have found it. </div><div><br></div><div>Nonetheless, a sentence or two in the release notes for Java 22, explaining this change would have been helpful.  </div><div><br></div><div>Thank you for your time and patience!<br><br>Lee.</div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div> </div><div><br></div><div><br></div><div> </div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Apr 26, 2025 at 3:25 PM Lee Rhodes <<a href="mailto:leerho@gmail.com" target="_blank">leerho@gmail.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"><div dir="ltr">Thank you for your explanation. <div><br></div><div>Cheers!</div><div>Lee.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Apr 26, 2025 at 1:06 PM Chen Liang <<a href="mailto:chen.l.liang@oracle.com" target="_blank">chen.l.liang@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"><div>




<div dir="ltr">
<div style="font-family:"Calibri Light","Helvetica Light",sans-serif;font-size:12pt;color:rgb(0,0,0)">
Hello Lee, for context, I believe this was changed in <a href="https://bugs.openjdk.org/browse/JDK-8321387" target="_blank">
https://bugs.openjdk.org/browse/JDK-8321387</a></div>
<div style="font-family:"Calibri Light","Helvetica Light",sans-serif;font-size:12pt;color:rgb(0,0,0)">
<br>
</div>
<div style="font-family:"Calibri Light","Helvetica Light",sans-serif;font-size:12pt;color:rgb(0,0,0)">
So this was mainly because in the implementation, the access methods aren't operating on the segment, but rather using the VarHandles - this means that those VarHandle may be passed either readOnly or modifiable segments, and they had been made to throw IAE
 instead of UOE, which was more correct.</div>
<div style="font-family:"Calibri Light","Helvetica Light",sans-serif;font-size:12pt;color:rgb(0,0,0)">
<br>
</div>
<div style="font-family:"Calibri Light","Helvetica Light",sans-serif;font-size:12pt;color:rgb(0,0,0)">
In addition, when you encounter this exception, usually you are working on a MS passed from parameters instead of one you allocated on your own - this is also an argument for IAE (for untrusted segments) instead of UOE (for trusted segments, you should have
 taken care at writing code or running tests).</div>
<div style="font-family:"Calibri Light","Helvetica Light",sans-serif;font-size:12pt;color:rgb(0,0,0)">
<br>
</div>
<div style="font-family:"Calibri Light","Helvetica Light",sans-serif;font-size:12pt;color:rgb(0,0,0)">
Also, do not rely on the behavior of preview features, which FFM was back in 21 - these features are not subject to backward compatibility in future releases, and this thrown exception change was done under this consideration.</div>
<div style="font-family:"Calibri Light","Helvetica Light",sans-serif;font-size:12pt;color:rgb(0,0,0)">
<br>
</div>
<div style="font-family:"Calibri Light","Helvetica Light",sans-serif;font-size:12pt;color:rgb(0,0,0)">
Regards,</div>
<div style="font-family:"Calibri Light","Helvetica Light",sans-serif;font-size:12pt;color:rgb(0,0,0)">
Chen Liang</div>
<div id="m_-577117417869702221m_2963948702780216446m_2518988633927578842appendonsend"></div>
<hr style="display:inline-block;width:98%">
<div id="m_-577117417869702221m_2963948702780216446m_2518988633927578842divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" style="font-size:11pt" color="#000000"><b>From:</b> panama-dev <<a href="mailto:panama-dev-retn@openjdk.org" target="_blank">panama-dev-retn@openjdk.org</a>> on behalf of Lee Rhodes <<a href="mailto:leerho@gmail.com" target="_blank">leerho@gmail.com</a>><br>
<b>Sent:</b> Saturday, April 26, 2025 2:31 PM<br>
<b>To:</b> <a href="mailto:panama-dev@openjdk.org" target="_blank">panama-dev@openjdk.org</a> <<a href="mailto:panama-dev@openjdk.org" target="_blank">panama-dev@openjdk.org</a>><br>
<b>Subject:</b> Exception change? and Reason?</font>
<div> </div>
</div>
<div>
<div dir="ltr">
<div>In Java 21 FFM, attempting a write operation on a MemorySegment configured as ReadOnly throws a <i>UnsupportedOperationException (UOE),</i> which makes sense.</div>
<div><br>
</div>
<div>However, starting with Java 22, FFM, attempting a write operation on a MemorySegment configured as ReadOnly throws a <i>IllegalArgumentException (IAE),</i> which makes less sense to me.   </div>
<div><br>
</div>
<div>I guess you could argue it either way, but one could look at it this way:</div>
<div>
<ul>
<li>The target is correct, but the operation is incorrect -- thus, UOE makes sense </li><li>The target of the operation is incorrect, but the operation is correct -- thus, IAE makes sense</li><li>The target is correct and the operation is correct, but the target is incorrectly configured as read-only -- thus UOE makes sense</li><li>Both the target and the operation are incorrect -- thus, either UOE or IAE could make sense.</li></ul>
</div>
<div>Of these 4 cases, I would think the first 3 are the most common, in which case the UOE would be the most likely cause.</div>
<div><br>
</div>
<div>I'm sure the Java authors must have a more eloquent reason why this was changed, and I tried to find release notes that would explain this change but to no avail.</div>
<div><br>
</div>
<div>Please enlighten me.</div>
<div><br>
</div>
<div>Lee.</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
</div>
</div>
</div>

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