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

Sergey Bylokhov serb at openjdk.org
Fri Mar 14 01:26:55 UTC 2025


On Wed, 12 Mar 2025 21:09:42 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> * Builtin color profiles may be cached during initialization or on first use. Changing a standard profiles after initialization using ICC_Profile.setData may not have the desired effect.
>
>> > Since there is no way to check if a profile is built-in, making built-in profiles read-only might be a better approach, similar to [java properties](https://bugs.openjdk.org/browse/JDK-8066709).
>> 
>> But it also has its own disadvantages...
> 
> @mrserb  You mentioned earlier that there are disadvantages of using java properties approach, so using builtIn flag would be better then, correct?
> 
>>  I remember we discussed this issue during the review of [this commit](https://github.com/openjdk/jdk/pull/3037/files#diff-3dd53a33889801159f43dbb990ba033066bdabaed71bbc7254f58331d3898d69R39), and the conclusion was that it was too late to change it and break apps.
> 
> I wasn't able to find the previous discussion thread so I'm not sure what are the disadvantages. Can you please explain?

If we start from the beginning. The problem we are trying to solve is preventing changes to our standard profiles so that we can be sure one part of the application does not unexpectedly affect another. This could be achieved in two ways:

- Throw an exception if a standard profile is modified
- Ignore the requested change and use the default profile properties as is

For new applications, we could require always cloning the color profile before modification (via the updated specification); otherwise, the application must always check whether the profile is built-in or not.

However, for older applications, these two solutions lead to different outcomes:

- Throwing the new exception will most likely break the application
- Ignoring the data change allows the application to continue working, but the color conversion result may not be fully accurate

The next question is: how big of an issue is this inaccuracy? For example, if we have an sRGB profile that rejects some modifications, we would still try to produce valid sRGB data during conversion.

So the trade-off is: broken applications vs. inaccurate (but still ICC-spec-compliant) conversions.

PS: By the way, why do we want to enforce this rule only for built-in profiles? Why can't a library create similar profiles and mark them as "read-only"?

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

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


More information about the client-libs-dev mailing list