On 5/9/16 11:44 PM, Wang Weijun wrote:
I have a question related.
There are some places in JDK that use doPrivileged to read "os.name" etc. This
system property is in the default java.policy file
On May 2, 2016, at 10:15 PM, Sean Mullan wrote:
This is not an issue in your changes, but the
I have a question related.
There are some places in JDK that use doPrivileged to read "os.name" etc. This
system property is in the default java.policy file
> On May 2, 2016, at 10:15 PM, Sean Mullan wrote:
>
> This is not an issue in your changes, but the current javadoc for
> Version.current
On 2016-05-02 16:15, Sean Mullan wrote:
This looks good.
Thanks!
* src/java.base/share/classes/jdk/Version.java
This is not an issue in your changes, but the current javadoc for
Version.current() says:
266 * @throws SecurityException
267 * If a security manager ex
On 05/02/2016 10:15 AM, Sean Mullan wrote:
This looks good. Just a couple of comments:
* src/java.base/share/classes/java/util/TimeZone.java
698 props.setProperty("user.timezone", id);
This will only change the local copy of the property. I think you want
to keep the original code whic
This looks good. Just a couple of comments:
* src/java.base/share/classes/java/util/TimeZone.java
698 props.setProperty("user.timezone", id);
This will only change the local copy of the property. I think you want
to keep the original code which does a System.setProperty.
* src/java.b
Hi,
JDK-8154231 added methods to simplify access to system properties from
internal code, but after some discussion it's been decided to rename
these methods and document them to make it abundantly clear that they
are performing a privileged action and that care needs to be taken to
tread the
