It's not really correct to say that URLClassLoader does not work with jar URLs.
What the submitter wants is to be able to load classes from a jar file nested
within another jar file, which is something we do not currently support.
Arguably, the spec for JarURLConnection implies that jar: urls can be nested,
but the implementatation (of URL) does not allow this. Similarly, the JarFile class does not lend itself to nested jar files readily. ie. you have to
read a JarEntry into a File and then create a new JarFile instance from that.
If we were to support reading classes from a nested jar file (even at only
one level of nesting) JarFile and JarEntry would need to support that
behavior directly (without having to create temporary files)
Aside form the generic nesting issue, it is also arguable that JarURLConnection
should support the case where the jar: url points to an entry that is a jar file
(which is the specific case in this report) but supporting this case, also
needs the same support form JarFile and JarEntry as above.
This requirement is documented in bug 4648386.
It seems that with the advent of ear, rar, and war files from J2EE such
nested JAR files are not uncommon, and it would be useful to be able
to load resources from them without having to extract individual archive
This issue and 4648386, probably should be targeted for the same release.
One problem with supporting nested jar files, is how to deal with compression.
Currently, ZipFile (and JarFile) instances are created from random access java.io.File
objects. Entries can be accessed at random, and an InputStream acquired to read the
contents of the entry. If the zip/jar is compressed, then an appropriate inflater or
decompressor is applied to the InputStream returned.
If we were to support nested jar files, then such nested files could no longer be
accessed in random order (because the data is only available as a stream). Of course, an
alternative would be to read the contents of the stream into a temporary file and then
use that file as the source for the nested JarFile instance, but in reality there
is nothing to stop applications from employing that kind of strategy today.
In principle, it might be possible to support nested jar files that are not compressed.
In that case, you could use the same File instance for both the parent JarFile
and the nested JarFile (with appropriate offsets to distinguish them),
but precluding the use of compression is too severe a restriction on jar files
to make the feature very useful.
For this reason, it does not seem to be feasible to support this right now.