For our SWT application I want to provide a generic Linux download bundle which can start on 32-bit- as well as 64-bit-VMs. Currently, we define the classpath using the manifest and start the application using java -jar main.jar. The manifest classpath contains multiple swt*.jars and the first matching one is picked (no problem, because currently only one is distributed for each platform).
Simply delivering both SWT libraries, swt-linux-32.jar and swt-linux-64.jar, looks not very promising, because then either the user would have to remove the wrong one manually or a script would have to set up the whole application classpath dynamically (scary!).
I’ve thought about providing two launcher scripts, one for 32-bit-VMs and the other for 64-bit-VMs, removing the swt.jars from the manifest classpath and adding the right one explicitly to the classpath, e.g. java -cp swt-linux-64.jar -jar main.jar. Unfortunately, it looks like one can’t mix explicit classpath definition (-cp) with implicit one (-jar).
One other solution could be explicitly set the classpathes in the launcher scripts, but this would make maintaining the scripts more complicated.
Of course, I would have the alternative to load the right swt.jar file dynamically in the application, but I’d prefer to keep the different file names out of the Java code.
Does anybody has some further better suggestion how we can manage it?
Easy: do dynamic classloader manipulation. Have a loader JAR that sets up a new URLClassLoader depending on the 32/64-bit type of the runtime, and then load your main class from there – then call the main method.