Re: RFR 8054536: sun.security.x509.Extension object may throw NPE for hashCode and equals method

Hi Svetlana, The webrev looks fine to me. Please see one more comment inline. On 07/15/2016 11:12 AM, Svetlana Nikandrova wrote: Hi Artem, ok, lets get rid of possible NPE in other methods too: http://cr.openjdk.java.net/~snikandrova/8054536/webrev.01/

RE: JDK-8152524

Hi All, This message is actually for Sean Coffey in relation to the JDK-8152524.  I saw the incident on the Web.  I am having a similar issue.  In the post, it is stated that this is being tracked elsewhere.  Can you tell me where?  I would like to know if it is being treated as an MS or McAfee

Re: Strange test failure when referencing a class in a deprivileged module

I discovered these bugs after writing a non blocking caching security manager and a couple of high scaling policy providers that combine immutability, atomic policy refresh and local variable confined mutibility.  The policy provider avoids unnecessary DNS calls by replacing URL with an rfc3986

Re: Strange test failure when referencing a class in a deprivileged module

Yes, I've come across this before, it will occur if you write a custom security manager or policy provider and either are in force before all their required classes have been loaded. SM implementors also need to be careful of Permission checks that require another permission check, as these cre

Re: RFR 8054536: sun.security.x509.Extension object may throw NPE for hashCode and equals method

Hi Artem, ok, lets get rid of possible NPE in other methods too: http://cr.openjdk.java.net/~snikandrova/8054536/webrev.01/ As for unnecessary try-catch in test I'd prefer to have it to emphasis that we are checking for NPE. I'm n

Re: RFR: 8159752: Grant de-privileged module permissions by default with java.security.policy override option

On 07/15/2016 10:50 AM, Weijun Wang wrote: Changes looks fine to me. One nit: Shall we put jdk.crypto.ucrypto into src/java.base/solaris/lib/security/default.policy? Yes, might as well fix that as part of this. Thanks, Sean

Re: RFR: 8159752: Grant de-privileged module permissions by default with java.security.policy override option

Changes looks fine to me. One nit: Shall we put jdk.crypto.ucrypto into src/java.base/solaris/lib/security/default.policy? --Max On 7/15/2016 4:05, Sean Mullan wrote: Please review this change to the default Policy provider implementation to grant de-privileged module permissions by default

Re: RFR: 8159752: Grant de-privileged module permissions by default with java.security.policy override option

The Makefile changes look fine. Tim On 07/15/16 04:51, Sean Mullan wrote: Adding build-dev for review since there is one change to a Makefile in the webrev below. Thanks, Sean On 07/14/2016 04:05 PM, Sean Mullan wrote: Please review this change to the default Policy provider implementation

Re: RFR: 8159752: Grant de-privileged module permissions by default with java.security.policy override option

Adding build-dev for review since there is one change to a Makefile in the webrev below. Thanks, Sean On 07/14/2016 04:05 PM, Sean Mullan wrote: Please review this change to the default Policy provider implementation to grant de-privileged module permissions by default even when the java.secur

Re: RFR: 8159752: Grant de-privileged module permissions by default with java.security.policy override option

> On Jul 15, 2016, at 4:05 AM, Sean Mullan wrote: > > Please review this change to the default Policy provider implementation to > grant de-privileged module permissions by default even when the > java.security.policy override option is specified or when the > Policy.getInstance API is used: