On 04/12/2014 15:42, 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 ?
As it happens I ran into a test a few days ago that was changing
java.home mid-flight. Lots of things can potentially go wrong when
changing an important property like (user.dir is another one).
It would have been nice if there had been a concept of final/set-once
system property a long time ago, hard to know if it's worth it now but
no harm trying if you can come up with something that wouldn't have a
significant compatibility impact. I could imagine System.setProperties
requiring work to merge in the new properties so that the important
properties are replaced.
-Alan.
