Exception change? and Reason?

[Lee Rhodes]

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/479a2821/attachment-0001.htm>