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 compliant uri, which uses bitshift case conversion during normalisation. I could donate parts of it that I've written under GPL, but would need to determine and contact all other authors to donate the entire works.
Needless to say Java's AccessController or AccessControlContext, are often incorrectly criticised for performance issues that originate in the policy provider. The rfc3986 compliant Uri class has an api identical to java's URI, although it isn't Serializable, it could be used to test the impact of rfc3986 on java platform libraries. Cheers, Peter. Sent from my Samsung device. Include original message ---- Original message ---- From: Peter Firmstone <peter.firmst...@zeusnet.au> Sent: 08/07/2016 05:53:47 pm To: WeijunWang <weijun.w...@oracle.com> Cc: jigsaw-dev <jigsaw-...@openjdk.java.net>; OpenJDK <security-dev@openjdk.java.net> Subject: 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 create recursive calls that can become infinite, but this won't occur in your simple test case. Regards, Peter. Sent from my Samsung device. Include original message ---- Original message ---- From: Weijun Wang <weijun.w...@oracle.com> Sent: 08/07/2016 01:18:56 pm To: Peter Firmstone <peter.firmst...@zeus.net.au> Cc: SeanMullan <sean.mul...@oracle.com>; jigsaw-dev <jigsaw-...@openjdk.java.net>; OpenJDK <security-dev@openjdk.java.net> Subject: Re: Strange test failure when referencing a class in a deprivileged module Mystery solved or problem solved? Have you fixed it somewhere else? Thanks Max On 7/7/2016 17:00, Peter Firmstone wrote: > Problem solved, even though it didn't occur on Java 8, the potential for > it to occur still exists there, it's simply that Java 9 seems to have > hit this execution path, it was a latent bug. > > Cheers, > > Peter.
