On Tue, 8 Jul 2025 05:26:16 GMT, Sergey Bylokhov <s...@openjdk.org> wrote:
> The ICC_Profile class has special logic to postpone actual data loading for > as long as possible. To support this we use a lightweight object that stores > commonly used metadata such as the number of components that can be accessed > without triggering full profile loading. But we currently discard this object > once the profile is used for color conversion since the application might > modify the profile data in a way that becomes inconsistent with what was > previously cached. > > After [JDK-8346465](https://bugs.openjdk.org/browse/JDK-8346465) all standard > ICC profiles bundled with the JDK are now immutable. This means the deferral > logic can be simplified: we no longer need to drop the lightweight metadata > object since the underlying data is guaranteed to remain unchanged. > > This patch includes two changes: > > 1. We > [stop](https://github.com/openjdk/jdk/pull/26179/commits/dea4d8cd2a2450841469a289824281142bccacce) > discarding the deferred metadata object. It will now used consistently > removing the need for a special flag to identify standard profiles. > > 2. While implementing the logic above I noticed a > [workaround](https://github.com/openjdk/jdk/pull/26179/commits/b40f97cddca3b260761553a1395ad2bac09b5fb6) > introduced for [JDK-8272860](https://bugs.openjdk.org/browse/JDK-8272860) no > longer applies. This workaround relied on getNumComponents() triggering > header profile loading which no longer happens for standard profiles. > Initially(at the moment the JDK-8272860 was filed) this caused test failures > but due to unrelated changes all those tests now pass. To ensure this issue > is still caught in the future, I’ve added a new test case that specifically > verifies this behavior. @honkar-jdk please take a look ------------- PR Comment: https://git.openjdk.org/jdk/pull/26179#issuecomment-3087560800
