Bill Shannon wrote:
> Finally returning to this (much too long) message.
Sorry for the length before. Just trying to explain clearly what I'm
thinking and why. Would you prefer to continue the discussion in a
phone call? I'll be brief here.
>
> Tim Quinn wrote:
>> I was hoping to avoid wrapping all the JARs into an umbrella JAR,
>> partly to streamline deployment. Also, to take best advantage of
>> Java Web Start's caching we would need to serve the individual JARs
>> separately.
>
> Yes, you need to keep the jars separate on the server for Java Web Start,
> but that doesn't mean you can't bundle them into one jar for the app
> client case.
Agreed. I was expressing a preference for avoiding different code paths
as much possible, rather than claiming an outright impossibility of
handling the two cases in different ways.
>> Also, I looked into this general idea a while ago. The comments in
>> forums from Java engineers at that time was that writing a class
>> loader to handle JARs within JARs was certainly possible but could be
>> very slow if the umbrella JAR were not expanded into a temp directory
>> and the class path set to the various expanded JARs.
>
> It's probably worth a day to find the technology and give it a try.
> (I really wish I could remember the name of it...)
I found a couple that might be what you're thinking of. I have not
experimented with either.
One-JAR
http://one-jar.sourceforge.net/index.php?page=introduction&file=intro
and
http://www.ibm.com/developerworks/java/library/j-onejar/ constructs,
before the user's code starts, an in-memory mapping from each class and
resource name in all bundled JARs to the byte[] for the class or
resource. One-JAR's custom class loader retrieves the pre-loaded byte
code from the map.
Seems OK for relatively small apps with relatively small supporting
libraries, but could be a memory hog and suffer slow start-up for larger
programs or libraries. I haven't found any performance information on
One-JAR on-line.
Jar Jar Links (lame Start Wars reference), on the other hand, is an ant
task and merges all entries from the specified JARs into a single JAR,
resolving any name conflicts using ASM byte code transformation to
rename classes and adjust the references to them. What looks like the
main site for this tool
http://tonicsystems.com/products/jarjar/ has
timed out for me on numerous attempts.
It may have trouble with code that loads classes dynamically using class
or resource names as strings if Jar Jar Links had renamed the subject
class or resource. There was also a mention of possible problems with
reflection.
At runtime this would seem faster and more memory-efficient than
One-JAR's approach but has the apparent problem with literal references
to resources and classes.
I have responses to the other technical points you raised. Let me know
if you'd prefer further mail or a phone call.
- Tim