Should some JDK system properties be read only ?

David M. Lloyd david.lloyd at
Thu Dec 4 16:34:23 UTC 2014

On 12/04/2014 10:21 AM, Seán Coffey wrote:
> On 04/12/2014 16:00, David M. Lloyd wrote:
>> On 12/04/2014 09:42 AM, Seán Coffey wrote:
>>> Apologies if this has been raised in past. 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.version, java.vm.vendor,
>>>, java.specification.version, java.specification.vendor,
>>> Should we consider making them read only for JDK 9 and later ?
>> Won't work unless you fundamentally change how System.setProperties()
>> works.  Right now it will accept a user-created Properties instance
>> and install it as the global system properties map.
> Some code change necessary but not much AFAIK. We can detect when JDK
> read-only values are (passed in && don't match orig. value) and throw an
> Exception or fail silently. Obviously a behavioural change which would
> require spec update.

You can't do so without wrapping or replacing the user-provided 
Properties object.  I guess wrapping is a reasonable option though.

More information about the core-libs-dev mailing list