> On Sep 14, 2018, at 4:02 AM, Sean Mullan wrote:
>
> webrev: http://cr.openjdk.java.net/~mullan/webrevs/8191053/webrev.00/
public static SecurityManager getSecurityManager() {
+if (allowSecurityManager()) {
return security;
+} else {
+return null;
+
On 9/13/18 4:50 PM, Stuart Marks wrote:
Hi Sean,
Looks sensible to me.
On 9/13/18 1:02 PM, Sean Mullan wrote:
2. A new JDK-specific system property to disallow the setting of the
security manager at run-time: jdk.allowSecurityManager
If set to false, it allows the run-time to optimize the
The test runs very slow on Linux and turns out reading from the embedded HTTP
server is the bottleneck. Here is the fix:
diff --git a/test/jdk/javax/xml/crypto/dsig/GenerationTests.java
b/test/jdk/javax/xml/crypto/dsig/GenerationTests.java
---
On 9/13/18 1:02 PM, Sean Mullan wrote:
This is a SecurityManager related change which warrants some
additional details for its motivation.
The current System.setSecurityManager() API allows a SecurityManager
to be set at run-time. However, because of this mutability, it incurs
a
On 9/13/18 2:43 PM, Sergey Bylokhov wrote:
Hello.
Please review fix for jdk12.
Bug: https://bugs.openjdk.java.net/browse/JDK-8210692
Webrev: http://cr.openjdk.java.net/~serb/8210692/webrev.00
CSR: https://bugs.openjdk.java.net/browse/JDK-8210693
Thus change looks okay to me. This class is
I'd guess that security-dev would have reviewers for the change to
default.policy. Cc'd.
s'marks
On 9/13/18 2:43 PM, Sergey Bylokhov wrote:
Hello.
Please review fix for jdk12.
Bug: https://bugs.openjdk.java.net/browse/JDK-8210692
Webrev: http://cr.openjdk.java.net/~serb/8210692/webrev.00
Hi Sean,
Looks sensible to me.
On 9/13/18 1:02 PM, Sean Mullan wrote:
2. A new JDK-specific system property to disallow the setting of the security
manager at run-time: jdk.allowSecurityManager
If set to false, it allows the run-time to optimize the code and improve
performance when it is
Hallo Sean,
The change looks fine to me, but if you have to roll another version maybe you
could add a comment on this line to explain its purpose. Since this line is
changed in the patch it would be a good time:
System.java:350
sm.checkPackageAccess("java.lang");
Is that some kind of
This is a SecurityManager related change which warrants some additional
details for its motivation.
The current System.setSecurityManager() API allows a SecurityManager to
be set at run-time. However, because of this mutability, it incurs a
performance overhead even for applications that
Hi all,
I am currently in the process of adding TLS 1.3 support into netty-tcnative[1]
which uses JNI to make use of OpenSSL for it. During this work I noticed that I
received test-failures when mutual auth is used and the JDK implementation is
used on the client side. When using the JDK
Looks ok to me too.
Brad
On 9/11/2018 8:43 PM, Jamil Nimeh wrote:
Looks good to me.
Thanks,
--Jamil
On 9/11/2018 7:22 PM, Xuelei Fan wrote:
Hi Jamil,
Would you please review the fix for the NPE issue:
http://cr.openjdk.java.net/~xuelei/8209916/webrev.00/
The issue may happen if the
11 matches
Mail list logo
