On Fri, 7 Mar 2025 01:37:53 GMT, Sergey Bylokhov <s...@openjdk.org> wrote:
>>>If an app got a profile 'from some place', it probably should not be trying >>>to change it, >> >> But this is not always possible. For example, a buffered image has a color >> model that references a color space and a color profile. To modify something >> in that profile(like intents screen vs printer) before converting the entire >> image, it is necessary to check whether it is a built-in profile. If it is, >> the whole image must be recreated; otherwise, an exception will occur. 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). >> >>>I don't see such a discussion there. Maybe it was 'offline' ? >> >> It was somewhere online not too long ago. > >>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... The System Properties case isn't something I'd want to follow. It doesn't really make them read-only. It just ensures that the JDK internally caches the original value for use in certain places. Consider this program public class jh { public static void main(String[] args) { String jhpstr = "java.home"; String jhp1 = System.getProperty(jhpstr); System.setProperty(jhpstr, "foo"); String jhp2 = System.getProperty("java.home"); System.out.println(jhp1+" " +jhp2); } } % java jh /Library/Java/JavaVirtualMachines/jdk-21.jdk/Contents/Home foo ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23606#discussion_r1987841827
