I've put together a little JarLoader class as an attempt to provide a facility for running standalone jarred applications. Basically it's an extension of Simon Tuffs one-jar sourceforge project which I can't recommend enough. It's a really great project and a wonderful introduction to the use of the JAR API.
He also has a great plugin for Eclipse that allows you to peer into jars in your workspace and amend them. Top notch stuff.
My problem is this:-
I have a jar like the following. ======================= JarA.jar | |-->ClassA.class |-->JarB.jar | |---->ClassB.class
i.e. jarA contains the class, ClassA, and a another jar, jarB. jarB contains the class, ClassB.
Using the jar api I can retrieve and load ClassB using the following code.
I've written a little catalog function that traverses a jar and catalogs all the classes that it finds. however, and this is the crux of the problem, it doesn't load them until the JarClassLoader is prompted for the class at runtime. i.e. lazy loading. I don't want to have to iterate over the entries in the internal file everytime I want to load a resource from it. The catalog function saves along with the description of the resource, the size of the resource and the offset into the archive where the resource began.
To calculate the offset, it simply increments an offset by the size of each entry it comes across during the original traversal. Alas I don't think this is giving me the correct offset value at all. When it comes time to load the resource, it finds the location of the archive, opens a JarInputStream to it and then skips along by the offset and attempts then to read the recorded number of bytes that should specify the archived entry. Alas this is not working for me.
Therefore while I can lazily load the classes I have to resort to iterating over all the entries within the archive where my resource resides. So while it's lazy it is not very fast. If I could implement this offset loading then surely it would be a lot faster especially in archives where there are hundreds of entries.
Anyone any ideas? Maybe someone is familiar enough with the JAR api to be able to recommend a better way to get the offset into the jar file? Perhaps this isn't plausible? Any suggestions are most welcome.
Thanks, Mark. [ November 29, 2005: Message edited by: Mark Gargin ]