RFR: 8358623: Avoid unnecessary data copying in ICC_Profile

Sergey Bylokhov serb at openjdk.org
Fri Jun 6 05:47:50 UTC 2025


On Thu, 5 Jun 2025 23:44:18 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> This PR simplifies several aspects of the ICC_Profile class:
>> 
>> - [Change 1](https://github.com/openjdk/jdk/pull/25650/commits/426a608b1df9e39e221d05e7374a3fecf6e6cf30):
>>     The ICC_Profile.getInstance(byte[] data) method used to copy the profile header for validation. This copy appears redundant, as the original data array is used later anyway. This logic was originally introduced by [JDK-8347377](https://bugs.openjdk.org/browse/JDK-8347377).
>> 
>> - [Change 2](https://github.com/openjdk/jdk/pull/25650/commits/4035c8b1f7e1dcbc9941ead939218bba47b0a2fe):
>>     In some places, the code retrieves the profile header using getData(icSigHead), which always creates a new array. It is now replaced with private getData(cmmProfile(), icSigHead) to avoid unnecessary copying. To clarify the purpose of the private method, I have added documentation.
>> 
>>  - [Change 3](https://github.com/openjdk/jdk/pull/25650/commits/96ad456593de3dd68c3ae6840fffee7bac68bc0c):
>> After Change 2, static analysis tools began reporting a potential NPE when using getData(cmmProfile(), icSigHead), since it may return null. To address this, the internal implementation of getData was updated to always return a non-null value or throw an exception. The public method now catches this exception and returns null, as required by the specification. **Note**: this potential NPE is not a regression introduced by any changes, it simply became easier for tools to detect due to the simplified code.
>> 
>> @prrace @honkar-jdk please take a look
>
> test/jdk/java/awt/color/ICC_Profile/CheckVersions.java line 61:
> 
>> 59:         }
>> 60:     }
>> 61: }
> 
> Also added a test for the changed methods, since they were not covered by any jtreg tests.

Interestingly, ICC_Profile.getMinorVersion() does not return just the minor version as specified, but instead returns the raw byte, which includes both the minor and patch versions. Perhaps the specification should be updated to reflect this behavior?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25650#discussion_r2130961674


More information about the client-libs-dev mailing list