3

I am aware that to combine several jars and create one executable jar, I would need to use a tool like OneJar if I don't want to unpack the dependent jars. OneJar has its own custom class loader which can find the required classes in the associated jars and load them.

My question is : Why is the default class loader not able to load classes from within the attached jars. Is it because of Security ? I would appreciate a clear explanation of the reasons behind the need for a custom class loader when creating a single executable jar which holds other dependent jars (without unpacking them). Thanks,

ajduke
  • 4,991
  • 7
  • 36
  • 56
Macky
  • 433
  • 2
  • 9
  • 22
  • Good question. I've wondered many times about this myself. – NilsH Apr 04 '13 at 06:51
  • 1
    I too don't know, but just now I searched about this and get one link as : http://stackoverflow.com/questions/8312909/java-create-jar-executable-with-dependant-jars-embedded. Hope, it helps you. – Bhavesh Shah Apr 04 '13 at 07:10
  • Thanks @TechnoCraft. I came across this post and as mentioned in the answer, the Classloader cannot find the embedded jar. I wanted to understand the reason for this. – Macky Apr 04 '13 at 08:30

4 Answers4

2

The technical reason is that the uri specification for jar: does not support nesting.

You could write a URI handler that addresses this need, but performance will start to hit as you nest down inside each jar file.

With a single jar file, random access is possible as the index gives file system offsets and you can seek each offset and read only the file you want

With a nested jar, you can seek the inner jar, but to pull a file out of that jar you have to unzip the inner jar from the outer before you can seek.

I would look at solutions such as those offered by either OSGi or by the Maven Shade Plugin if you don't want to extract the jar files to a temporary directory and build your own classloader from the resulting classpath

Stephen Connolly
  • 13,872
  • 6
  • 41
  • 63
  • Thank you @Stephen. I just wanted to understand the reason for this not being possible. – Macky Apr 04 '13 at 08:23
1

In addition to other answers (the one from Stephen being the more accurate so far), also consider that the JVM does not preemptively explore the available classpath entries, so in order to find class com.foo.Bar it will look at a path like com/foo/Bar.class in the entries listed in the classpath. If this path could be inside a nested jar (that is not itself listed in the classpath declaration), in order to find said path the classloader should first explore all the nested jar (unpacking them in the process) in order to do the appropriate lookup.

Grim
  • 1,608
  • 9
  • 12
  • Thanks @Grim. Would I be correct in saying that Eclipse's Create Runnable Jar option that packages all dependencies within a jar along with its own jarinjar loader is implementing its own ClassLoader? – Macky Apr 04 '13 at 09:29
  • 1
    Correct, see [this question](http://stackoverflow.com/questions/12573302/the-magic-behind-the-eclipse-generated-executable-jar-file) and the relevant answer. – Grim Apr 04 '13 at 09:37
0

I doubt the decision is due to security: it would be surprising if anything is made more or less secure by being nested. In fact it might be quite nice to be able to sign all JAR's as a whole in my uber-JAR and have them all checked for integrity as part of verifying my JAR.

I would think the main reasons are performance and simplicity. If JAR's can be nested, what should be the answers to these questions:

  • How much nesting is allowed? Can you have JAR's within JAR's within JAR's?
  • In the case where a class is in two JAR's, which is used?
  • JAR's can be indexed: how would that index account for the contents of nested JAR's?

It seems most straightforward to think of a JAR just like a shared library: it's a nice, packed, indexed, signed, flat, ready-to-link package. It's notable that Unix .so's and Windows .dll's also do not allow nesting, and for much the same reasons I suspect.

Side note: creating "uberjar's" in general is often not needed: you can usually use the Class-Path field in the main JAR's manifest to allow it to pull in external libs.

Matthew Phillips
  • 1,275
  • 1
  • 12
  • 19
0

You can place all jars your app needs in you app folder (eg lib) and either use java -cp lib/*.jar ... or enumerate all jars in main jar's manifest Class-Path attribute.

Evgeniy Dorofeev
  • 133,369
  • 30
  • 199
  • 275