RFR: JDK-8346465 : Add a check in setData() to restrict the update of Built-In ICC_Profiles [v5]

Harshitha Onkar honkar at openjdk.org
Mon Feb 24 19:14:53 UTC 2025


On Mon, 24 Feb 2025 17:09:38 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>>> > And two @throws with the same type aren't allowed in javadoc, which means you have to add the new reason to throw IllegalArgumentException into the existing one.
>>> 
>>> That's demonstrably untrue. This method already has two.
>> 
>> I was wrong here, the specification for [`ICC_Profile.html.setData`](https://docs.oracle.com/en/java/javase/23/docs/api/java.desktop/java/awt/color/ICC_Profile.html#setData(int,byte[])) correctly displays the two entries for `IllegalArgumentException`. The generated javadoc for the proposed changeset contains three entries for IAE.
>> 
>> I misremembered it, or it was a limitation in an IDE javadoc parser.
>
>> Regarding the scenario above, this apparent and has all been considered already and the IAE is the preferred solution.
>> 
>> And FWIW I don't think ISE is really any better.
> 
> <code>Illegal<i>Argument</i>Exception</code> implies the *argument* is invalid, but it is now thrown for a *valid* argument if the object *state* doesn't allow modifying the data.
> 
> <code>Illegal<i>State</i>Exception</code> conveys the object *state* is inappropriate to call this method.
> 
> There's a semantic difference between the two, and I think <code>Illegal<i>State</i>Exception</code> is better in this case.
> 
> We can also discuss it with Joe in the CSR.

@aivanov-jdk  As Phil mentioned earlier the already documented exception IAE for `.setData()` outweighs introducing a new exception. Using an existing exception would mean less disruption to any existing applications using the Java API.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23606#discussion_r1968263836


More information about the client-libs-dev mailing list