Hi Max,
On 6/4/2018 7:24 PM, Weijun Wang wrote:
Hi Roger
Thanks for the explanation.
Another question: Before this change, a SecurityException might be thrown when
getProperty() is called, does you new code simulate this behavior? Or in these
cases this is unnecessary?
Many of the usages were already in doPriv or GetPropertyAction flows so
no security check was being done.
In a few cases, the existing doPriv is in a different file (e.g. calls
to SunEntries.getDeviceFile(utl)).
Those would be safer to leave as is, trading off the consistency with
confidence about the property check
(or add the property access check).
The usage in SocksSocketImpl needs a second look, Alan pointed out a
difference in behavior.
The use of user.name in MimeTable and MailToURLConnection were missing a
security check.
Also, looks like all change is inside java.base, do you have a suggestion we
use it in other JDK modules?
Not at this time.
Roger
Thanks
Max
On Jun 5, 2018, at 3:54 AM, Roger Riggs <roger.ri...@oracle.com> wrote:
Hi Max,
On 6/4/2018 11:41 AM, Wang Weijun wrote:
Not a native English speaker, so my feeling might be incorrect.
Will someone interpret this as that System.getProperty() will return a cached
value?
I don't think so, it should be clear that the values are cached at
initialization or first use.
I would say “Although getProperty() always returns the last value set by setProperty() (I
assume this is the current behavior), it is not uncommon that consumers of a system
property may read it once and cache the value it for later use, which means setting the
property <strong>may not have the desired effect</strong>”.
The purpose of the change is to clarify the behavior of the java.base module
internal access to the properties.
How applications handle properties is beyond the intended scope.
I also don’t think it’s worth listing the 4 property names in the spec. Quite
some other system properties are also cached. Listing them there could further
suggests that calling getProperty() on them will return the cached value.
It seemed worthwhile to highlight the specific properties affected and the
release note should be specific.
I moved them to an implNote as Alan suggested.
Thanks, Roger
Thanks
Max
在 2018年6月4日，下午9:32，Roger Riggs <roger.ri...@oracle.com>
写道：
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
Thanks, Roger
