Bug ID: JDK-8066709 Make some JDK system properties read only

JDK-8066709 : Make some JDK system properties read only

Type: Enhancement
Component: core-libs
Sub-Component: java.lang
Affected Version: 9

Priority: P3
Status: Resolved
Resolution: Fixed

Submitted: 2014-12-04
Updated: 2019-10-25
Resolved: 2018-06-27

Versions (Unresolved/Resolved/Fixed)

The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.

JDK 11	JDK 12
11 b20Fixed	12Fixed

Related Reports

Blocks :	JDK-8201279 - javax.sound tests should not set java.home system property
Blocks :	CODETOOLS-7902139 - jtreg should not set system property java.class.path
CSR :	JDK-8204235 - Make some standard system properties effectively read only
Relates :	JDK-8176456 - Clearing system property user.dir causes File methods to throw NPE
Relates :	JDK-8185496 - Improve performance of system properties initialization in initPhase1
Relates :	JDK-4165411 - java.lang.System: Forbid the modification of read-only system properties
Relates :	JDK-8233020 - (fs) UnixFileSystemProvider should use StaticProperty.userDir().

Sub Tasks

JDK-8206908 :

Release Note: Make Some System Properties Effectively readonly - Closed

Description

I've run into issues in the past where bad user code (app server) has set the java.home system property to a value other than the default. This has consequences for apps/code that depend heavily on java.home returning the correct location. The case I saw was a JDK 7 runtime attempting to load JDK 6 config files (since java.home was pointing to JDK 6)

It leads me to question on whether we should change this behaviour. There are a whole bunch of properties that make no sense to change.
Those like : java.version, java.vendor, java.home, java.vm.specification.version, java.vm.specification.vendor, java.vm.specification.name, java.vm.version, java.vm.vendor, java.vm.name, java.specification.version, java.specification.vendor,java.specification.name.

Should we consider making them read only for JDK 9 and later ?

Comments

An oversight, created 8233020 to fix it.
25-10-2019
The changeset for this bug changed the constructor of WindowsFileSystemProvider to use the new StaticProperty.userDir(), but the constructor of UnixFileSystemProvider still uses the system property {{user.dir}}. This means that there is now a semantic difference between operating systems. Was there a reason for this difference or was that an oversight?
25-10-2019
This is a dup of JDK-4165411.
11-01-2018
mail discussion at http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-December/030099.html
04-12-2014