Should some JDK system properties be read only ?
David M. Lloyd
david.lloyd at redhat.com
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.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 ?
>>
>> 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.
--
- DML
More information about the core-libs-dev
mailing list