URLClassLoader.getPermissions() attempts to return the appropriate "dynamic
permissions" to grant to a class with a given CodeSource; it also verifies that
the class loader's access control context has all of the dynamic permissions
that it would grant. If the CodeSource's URL is a "file:" URL, it grants
permission to read the file or directory's contents; otherwise, it grants
"connect,accept" permission to the URL's host.

Say the CodeSource's URL is a "jar:" URL with the JAR file named with a
"file:" URL. This "jar:" URL will get treated like all other
non-"file:" URLs: the classes will be granted "connect,accept"
permission to their codebase host, instead "read" permission of the JAR
file. Not only does it seem to give the loaded classes the wrong
permissions, but the more immediate problem is that is will result in a
security exception if the class loader doesn't have the
"connect,accept" permission, which it very well might not. The RMI
class loader now grants itself the minimum permissions it thinks that
it needs, "connect,accept" to the host of a "jar:file:..." URL not
being one of them. Thus, a security exception will be thrown.

For a "jar:" URL that points to a JAR file with a "file:" URL, the appropriate
dynamic permission to grant would be a FilePermission to "read" the JAR file.