Users with NoClassDefFoundError & nested jars - PLEASE READ!!

Question

A hell of a lot of the traffic on this forum is to do with getting a NoClassDefFoundError while trying to access classes that are inside a jar within your own jar.........please please please read this if you're having this problem, it will explain what's going on, and will save you from having to post the same question for the millionth time!!!
Unfortunately you can't embed jars within a jar and expect them to be referencable for the classpath from outside the main jar. The "Class-Path" attribute in the manifest is used to refer to other jar files outside of your jar file.
The usual approach to solve this problem is to unpack the jar files you want to embed and then rejar everything together in one big jar file again. This isn't always a great approach though, I know I'm looking for an alternative. So far my only alternative is dynamic class loading using a classloader, however this isn't great if you need to refer to several hundreds or even thousands of classes.

Answer 1

As I replied in another post (http://forum.java.sun.com/thread.jsp?forum=22&thread=416726&tstart=0&trange=100) I think Sun should really add this capability to the JVM itself. Perhaps a new file format, .aar (for Application Archive) that the JVM DOES read embeded .jar/.zip files from. Even if it is only one level deep, that would be extremely helpful. I have built a plugin engine and originally was packaging my plugins in .jar files. But if a plugin "wraps" a library like ant.jar or something, you are out of luck, the plugin has to be un-archived to the disk for it to work. We came up with a solution, which is a .par file (for plugin archive) that does embed everything, but the engine itself at runtime un-archives the .par file into a "working" directory behind the scenes. While this does work, the main problem is if you deploy an app with a lot of plugins it takes a while to un-archive everything before the app initially starts.
Our next step is to do what Carter says, build a custom jarjar classloader. That is, we'll extend URLClassLoader, and in the loadClass() call (for our plugin engine we break the normal go to parent loader first tradition) we'd have to "scan" a plugin .par file for any .jar files. If the .par file contains .jar files, we then retrieve those and scan them in memory for the class we are looking for.
As I explained there are no doubt several ways to make this fast. The classloader would want to keep a list of all packages found and in what .jar/.zip they were found in, so as more classes within the package of a given .jar are asked to be loaded, the engine knows exactly what .jar/.zip to jump to. Also, OS hd caching will most likely take affect somewhat thus if many classes from the same .jar file are required it is possible that .jar file would be cached and multiple i/o access will not take place.