Exception change? and Reason?
Chen Liang
chen.l.liang at oracle.com
Sat Apr 26 19:56:20 UTC 2025
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/8e41406c/attachment.htm>
More information about the panama-dev
mailing list