RFR: JDK-8347377 : Add validation checks for ICC_Profile header fields [v9]

[Phil Race]

On Tue, 21 Jan 2025 20:06:55 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> ICC_Profile.setData(..) does validation of the specified tag contents and throws an exception if it is not valid. But if the tag represents the header, at least some of the validation is lazy, occurring only when the data is used, leading to unexpected exceptions at a later time. The check should be done up-front when the data is set, as in other cases.
>> 
>>  `verifyHeader(byte[] data)`is called when header data is being updated and the following fields are validated according to the ICC Spec Document. [[1] Pg#19](https://www.color.org/specification/ICC.1-2022-05.pdf). 
>> 
>> - Profile/Device class
>> - Color Space
>> - Rendering Intent
>> - PCS
>> - Header Size check (ICC Header Size = 128 bytes)
>> 
>> These validation checks are added to ICC_Profile.getInstance(..) & ICC_Profile.setData(..) methods.
>> 
>> Reference: [1] https://www.color.org/specification/ICC.1-2022-05.pdf
>
> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Runtime Exception added

ICC specifies 4 rendering intents, no more. And is clear that these are the 4 ICC rendering intents.

Non-ICC intents are not something we'd support. I see absolutely no problem with that.
If a profile has an intent that is unknown to JDK APIs, it doesn't matter what LCMS might do with it
if you were programming directly to LCMS as a CMM.
Who knows how many things we'd have to do in order to support 'custom' ICC intents.

For Color Spaces, the ICC spec. says
"The names and signatures of the permitted data colour spaces are shown in Table 19."

The word "permitted" makes it clear that anything not in this table is not permitted, and thus illegal.

So in summary, the changes made here are all fine.

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

PR Comment: https://git.openjdk.org/jdk/pull/23044#issuecomment-2619867896