On Mon, 10 Mar 2025 18:47:17 GMT, Phil Race <p...@openjdk.org> wrote:
>>>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 > There are two other exceptions that may be better suited that ISE in this > case - [UnsupportedOperationException > ](https://docs.oracle.com/en/java/javase/23/docs/api/java.base/java/lang/UnsupportedOperationException.html) > and > [ProfileDataException](https://docs.oracle.com/en/java/javase/21/docs/api/java.desktop/java/awt/color/ProfileDataException.html) > but still IAE was chosen over them as it is existing and documented > exception. `UnsupportedOperationException` could be used. `HeadlessException` extends `UnsupportedOperationException` and indicates a situation where a method cannot proceed because of the platform configuration. `ProfileDataException` doesn't suit either because there's nothing wrong with the profile data in the case of built-in profiles. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23606#discussion_r1990040755
