Exception change? and Reason?

[Lee Rhodes]

Chen,

(Continued... 🙂 )

To follow your explanation I found and examined the internal
*AbstractMemorySegmentImpl.java* and it makes sense that
*layout.varHandle().set((MS)this,
...) *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.

>From a normal user of the public API, this is pretty subtle because the
MS::set(...) method appears to operate on the MS.

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.

Nonetheless, a sentence or two in the release notes for Java 22, explaining
this change would have been helpful.

Thank you for your time and patience!

Lee.














On Sat, Apr 26, 2025 at 3:25 PM Lee Rhodes <leerho at gmail.com> wrote:

> Thank you for your explanation.
>
> Cheers!
> Lee.
>
> On Sat, Apr 26, 2025 at 1:06 PM Chen Liang <chen.l.liang at oracle.com>
> wrote:
>
>> Hello Lee, for context, I believe this was changed in
>> https://bugs.openjdk.org/browse/JDK-8321387
>>
>> 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.
>>
>> 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).
>>
>> 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.
>>
>> Regards,
>> Chen Liang
>> ------------------------------
>> *From:* panama-dev <panama-dev-retn at openjdk.org> on behalf of Lee Rhodes
>> <leerho at gmail.com>
>> *Sent:* Saturday, April 26, 2025 2:31 PM
>> *To:* panama-dev at openjdk.org <panama-dev at openjdk.org>
>> *Subject:* Exception change? and Reason?
>>
>> In Java 21 FFM, attempting a write operation on a MemorySegment
>> configured as ReadOnly throws a *UnsupportedOperationException (UOE),* which
>> makes sense.
>>
>> However, starting with Java 22, FFM, attempting a write operation on a
>> MemorySegment configured as ReadOnly throws a *IllegalArgumentException
>> (IAE),* which makes less sense to me.
>>
>> I guess you could argue it either way, but one could look at it this way:
>>
>>    - The target is correct, but the operation is incorrect -- thus, UOE
>>    makes sense
>>    - The target of the operation is incorrect, but the operation is
>>    correct -- thus, IAE makes sense
>>    - The target is correct and the operation is correct, but the target
>>    is incorrectly configured as read-only -- thus UOE makes sense
>>    - Both the target and the operation are incorrect -- thus, either UOE
>>    or IAE could make sense.
>>
>> 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.
>>
>> 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.
>>
>> Please enlighten me.
>>
>> Lee.
>>
>>
>>
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/panama-dev/attachments/20250426/4f3e4987/attachment.htm>