New candidate JEP: 411: Deprecate the Security Manager for Removal

Peter Firmstone peter.firmstone at
Thu Apr 29 21:11:36 UTC 2021

On 29/04/2021 10:57 pm, Sean Mullan wrote:
> On 4/29/21 1:37 AM, Peter Firmstone wrote:
>> We have our own security manager implementation and policy provider 
>> implementations.  Both of these are high performance and non-blocking 
>> and we are able to dynamically grant and revoke some permissions. 
>> While I acknowledge the Java policy implementation has a significant 
>> performance impact, due to blocking permission checks, ours is less 
>> than 1%.  Our software doesn't share PermissionCollection instances 
>> among threads, or even have a Permissions cache, 
>> PermissionCollection's are generated for each permission check and 
>> discarded for garbage collection, the Permission object themselves 
>> are cached (after initialization and safe publication), as are the 
>> results of repeated permission checks. We also have our own 
>> Permission implementations.
> Yes, you and I had discussions about this several years ago and I 
> believe I asked if you would be willing to donate these performance 
> improvements. I can't remember but I think you had interest in doing 
> that but couldn't make it happen for some reason.
Licensing, parts of the code I could donate as I am the original author, 
but other parts were AL 2.0 licensed by others, I think I found some 
AL2.0 code in OpenJDK at the time, but I was having trouble getting 
clarity around licensing, I don't remember the details but I think I 
needed to contact the other authors and have them sign contributor 
agreements or rewrite their code.

The two components that caused licensing issues were the policy parser 
(although Java has it's own, so not a major issue) and an RFC 3986 URI 
implementation which replaced URL, which was heavily utilised, it 
normalizes URI for policy implies checks, including RFC 5952 IPv6 
address normalization, OS specific file based URI were normalized 
dependent on the underlying OS (eg uppercase for Microsoft).  Using 
Java's URI wasn't an option as it wouldn't normalize appropriately, 
while using URL would cause blocking network calls.

It is a strict RFC 3986 implementation, Unicode characters beyond 
US-ASCII are escaped, and it utilises bit shift operations during 
normalization, it's also immutable and not serializable, so it wasn't a 
backward compatible replacement for Java's URI.

The difference between URI and URL use in policy files, was that if two 
different domain names resolved to the same IP Address, they implied 
each other under a URL ( required blocking network dns calls), while 
they didn't imply one another under URI.   This had the added benefit of 
allowing one domain name to resolve to multiple IP addresses without 
having to add multiple IP addresses to policy files, for example 
fail-over web server addresses.

Some trivia, I also wrote a URIClassLoader that replaced URLClassLoader, 
specifically to override behaviour in SecureClassLoader, where URL's are 
used as key's in a cache, again for performance reasons.

Re-implementing RFC 3986 URI functionality was a significant 
undertaking, I wasn't familiar with  OpenJDK's build system, was busy 
with other things so I put it off until later... which hasn't happened 
yet lol.

Peter Firmstone
Zeus Project Services Pty Ltd.

More information about the security-dev mailing list