What is the best practice for including third party jar files in a Java program?

A:

You can try the Fat-Jar solution, it works perfectly with the 'Fat Jar Eclipse Plug-In'. I have used for a few projects with no problems at all. The principle of it seems to be the same of your current solution.

bpfurtado 2010-03-13 04:05:07

If I'm reading that right it just handles the packaging for my distribution, and not for users upgrading their external libraries?

ZoFreX 2010-03-13 04:14:39

@bpfurtado: +1, or use "izpack"... Or do the same yourself, it's not hard.

Webinator 2010-03-13 04:16:05

fat-jar is just about packaging and it does not provide a upgrading mechanism for the included libraries. Regarding your difficulties to dubug using a custom Classloader, I just do all development/debugging inside my IDE and after that I use fat-jar to make the deployment, all tests left to make with the 'packed' solutiuon would be related to 'ClassNotFoundException's, what never happens, since 'fat-jar' works pretty well.

bpfurtado 2010-03-14 14:17:39

I haven't tested Fat-Jar but many methods of repacking everything into one jar can slow things down. It's also worth noting that repackaging like this is often not allowed by the licenses of third party libraries, especially if the application itself is not under the same license (in my case it is not open source).

ZoFreX 2010-03-14 19:57:46

Slow things down? How? You mean something like the application startup time? Because I don't see it slowing the development time.Regarding licenses, you'll have the problem no matter the technical solution you use... I thought you wanted a technical solution. Fat-Jar does exactly what you tried to do yourself, but it's pretty stable, I never saw it crashing and I used it a lot. You don't need to 'reinvent the wheel', that way you can focus on your application unique features ;)

bpfurtado 2010-03-14 23:36:15

I mean startup time, not development time. Some licenses allow bundling but not repacking, if they don't allow bundling then other approaches listed here will let the end-user drop them in themselves. It's a neat solution for some situations, but it doesn't meet my main criteria (upgrading).

ZoFreX 2010-03-15 20:49:48

+2 A:

We provide script files with the jar. E.g. some.bat, some.sh etc.

And as of Java6, you can use wildcard to specify classpaths.

Here is a good article that explains this approach : http://blogs.sun.com/mr/entry/class_path_wildcards_in_mustang

Enno Shioji 2010-03-13 04:07:46

@Zwei steinen: he wants to be cross platform. Java 6 means you'd cut yourself from a huge part of the OS X userbase which have Macs that shall never officially have Java 6 (32 bits CPU Macs).

Webinator 2010-03-13 04:10:39

Ehhhh for this project OS X compatibility isn't really a biggy, and I've been compiling against 1.6 anyway. Thanks for the tip though, I will have to check that my other projects work on 1.5!

ZoFreX 2010-03-13 04:15:55

I'm going to specify the classpath in the jar manifest and require that the end-user names third party libraries correctly when they upgrade them. However, I'm marking this one as accepted as it had the most cool information.

ZoFreX 2010-03-15 20:51:37

A:

I think I'm going to go the manifest route. Declare the classpath in the manifest for the entry jar, and have entries for:

libs/pircbot.jar
libs/mysql-connector-java-5-bin.jar
libs/c3p0.jar

Then if users want to upgrade to the latest library versions, they will have to rename them to match what is declared in the manifest. I don't think that's too big a hassle, and it makes things a lot simpler internally.

I also just generally don't like the idea of loading everything in ./lib/ automatically, that seems potentially dangerous.

ZoFreX 2010-03-14 19:56:32

+1 A:

If your audience is technical (and it sounds like they are if they're willing to drop in new jar files) then perhaps you could supply .sh and .bat files that they can edit to modify the classpath? That will be more transparent to them than a custom classloader.

Brian Slesinsky 2010-03-14 22:21:04

This isn't a bad approach but it does complicate things when they update the main program jar, as their changes would need to be re-done. I think overall requiring them to rename the files is the best approach, but if there are complaints I will probably go down this route.

ZoFreX 2010-03-15 05:40:15

ansaurus

tags:

views:

answers:

What is the best practice for including third party jar files in a Java program?

related questions