Hi Alan,
Updated webrev in place:
http://cr.openjdk.java.net/~rriggs/webrev-static-property-8066709/
On 6/4/2018 12:21 PM, Alan Bateman wrote:
On 04/06/2018 14:32, Roger Riggs wrote:
Please review a change to make the values of java.home, user.home,
user.dir, and user.name
effectively read-only for internal use. The values are cached during
initialization and the
cached values are used.
Webrev:
http://cr.openjdk.java.net/~rriggs/webrev-static-property-8066709/
Issue:
https://bugs.openjdk.java.net/browse/JDK-8066709
CSR:
https://bugs.openjdk.java.net/browse/JDK-8204235
Can the @apiNote be split up so that the list of 4 properties moves to
an @implNote? Also "changing any standard property" may need
clarification as it can mean both changing a system property in a
running VM and also changing it by starting the VM with a value for
one of these properties.
ok, will clarify that setting the properties using setProperty or the
getProperties().set() methods after initialization
may have unpredictable effects.
I think I agree with Max on finding another name for the internal
class as it is a class to get the original value of a few critical
properties. Also I think we need to look at other ways to do the
initialization, maybe in conjunction with VM.saveAndRemoveProperties
so that we are saving the initial values of properties in one place.
There is a future, more comprehensive change that will address a more
consistent model for system properties.
For now the task is to reduce the impact of inadvisable programmatic
setting of standard system properties
for a few of the most (likely to be) abused properties.
Are the changes to SocksSocketImpl correct? I may have missed
something but the original called System.getProperty("user.dir") in a
privileged block so I'm wondering if getUserNameChecked is needed.
The existing code in SocksSocketImpl is inconsistent with respect to
access to user.name; some flows
use doPriv to access the property and others did not. If someone
familiar with the Socks networking function
can recommend the proper access, it can be revised. The intent was to
have the same security checks
as before.
The static USER_DIR can be dropped from WindowsFileSystemProvider as
there is only one instance of the provider.
ok
The other usages look okay to me.
Thanks, Roger
-Alan
