How to use a jar from another jar

Newbie & Debugging Questions
#1

I’m working on a game that takes joystick input. I like to package my software into jar files, it’s easier to download that way. However, I still need a batch file to run it that looks like this:
java -cp JInput.jar -jar MyGame.jar
Is there any way that I can embed the JInput in my jar?

#2

a) fat jars… that is… extract em (first libs, then yours) and compress the whole thing.
b) putting the jar into the other jar and doing some classloader voodoo (xjar)
c) well, you can always use webstart :wink:

#3

There is a classpath entry in the jar manifest.
Any jar you name there will become part of the classpath when you run that jar using java -jar

This is what the SGS in the SDK does.

#4

Last I checked, this was not a robust solution since one cannot use variable expansion in the manifest. I haven’t tried it in cases where all of the jars in are the same folder, and maybe that works okay, but I don’t think it works when the jars are spread about the user’s system. Hence I’ve been forced to write launchers to run my programs, since the locations of libraries (specifically tools.jar) changes from system to system. Of course, if anyone has a better idea, I’m open to it :wink:

#5

[quote] since the locations of libraries (specifically tools.jar) changes from system to system.
[/quote]
This is even less robust because you don’t know if a user has the JDK.
You could write a classloader which adds jars from a directory to the classpath, if you need something like that.

#6

shrug

Depends on what you want to use it for. In the SGS SDK we assume you are running from the root directory and havent cfhanged the inatalled layout.

If you dont match those criteria, you just have to write your own CLASSPATH. I dont see a problem with this-- the manifest entries are just a convenience, they don’t keep you from doing things the hard way if you want to.

#7

This is even less robust because you don’t know if a user has the JDK.
(snip)
[/quote]
Agreed, and that’s why I had to write a launcher for the program: need to find the JDK install, its tools.jar, add it to a classpath, then launch the app. I should have clarified the context: my team (at the time) was hoping to run the application as a single executable jar. However, the tools.jar is system-dependent, so it seemed foolish to attempt to repackage our tool for every single java installation; this would lead to a maintenance nightmare, if it would even work at all. Java WebStart allows you to run an app with multiple jars instead of one executable jar; however, I don’t think you can get to the user’s JDK install automagically that way either. Hence, we’re stuck with a custom launcher that does the work of hunting down the installation.

I didn’t mean to imply that manifest classpaths are bad; just that they’re not robust. They work perfectly for many applications, but they are useless for any case where you do not know the directory structure of the client ahead of time, and they break if the client makes changes to that structure.

#8

There’s a Request For Enhancement about that here, I just voted for it. Put a vote in too :slight_smile:

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4648386

#9

I have used this before, fairly simple solution.

http://one-jar.sourceforge.net/

Basically does allthe classloader voodoo for you, and allows you to bundle everything in a single jar

#10

Thanks for that. I tried and failed to find this out but maybe you could tell me:

Does its classpath-voodoo work with Web Start? (so a Web Start jnlp file can point to that single jar alone & Web Start will work even though Web Start uses its own special class loader?)

Keith