RFR: 8229773: Resolve permissions for code source URLs lazily

Alan Bateman Alan.Bateman at oracle.com
Thu Aug 15 10:56:30 UTC 2019

On 15/08/2019 11:03, Claes Redestad wrote:
> Hi,
> by resolving permissions for code source URLs lazily, we can reduce
> early class loading during bootstrap, which improves footprint, startup
> and reduces the typical bootstrap dependency graph.
> Bug:    https://bugs.openjdk.java.net/browse/JDK-8229773
> Webrev: http://cr.openjdk.java.net/~redestad/8229773/webrev.00/
> :
I think the approach is okay as URL::openConnection doesn't actually 
open the connection to the resource and the creation of the 
URLStreamdHandler shouldn't depend on permissions granted to the caller. 
If a handler needs permissions when creating the URLConnection then it 
should do so in a privileged block. I think it would be a bit cleaner if 
the supporting class would lazily add the permissions for a CodeSource 
to the collection. That is, create it with a permissions collection and 
code source rather than a URL to match 
SecureClassLoader::getPermissions. You could potentially use it in 
URLClassLoader getPermission(CodeSource) method too.

In System.setSecurityManager then you might need 
DefaultFileSystemProvider.theFileSystem() to ensure that the default 
file system is fully initialized before setting the SM.

A minor nit this adds a spurious import BuiltinClassLoader. Also it can 
import the sun.security.uti class to be consistent with the existing code.


More information about the core-libs-dev mailing list