Irritating Java Environment
Debian/Ubuntu has what I think is pretty dumb Java environment.
Basically, jar files are not automatically found in /usr/lib/java/ and JNI libraries are not automatically found in /usr/lib/jni, requiring you to create a goofy little shell script for every Java app you write that sets these things if you need them. Any Java app that uses external JAR files or JNI files (.e.g., SWT) is instantly made non-portable by the fact that you have to set weird system-specific path settings instead of just being able to run java -jar myapp.jar.
The justification for this seems to be, “well, users might have multiple JVMs, and /usr/bin/java alternative might not be set to the most complete/featureful one, and since we only support software packaged officially for Debian**, we just recommend that packagers include scripts that set the specific JVM and classpath and so on they need, and never ever use the essentially useless /usr/bin/java command.”
Here’s an idea: make /usr/bin/java a system wrapper around the chosen alternative that automatically sets things up so the required JAR files located in the manifest of apps are found without the Debian-specific paths and so that the library search path is set so the Debian-specific /usr/lib/jni path is used for loading JNI shared objects. Then shit will actually work. For the users who set their java alternative to point to some incomplete or non-functional JVM, tell them to kiss your ass and install a JVM that will actually work.
** And this, folks, is still the #1 usability killer in Linux. If it isn’t part of the pre-selected set of almost certainly out of date software packages shipped by the specific version of the specific distribution you’re running, the software is a complete and total bitch to install and use, even when that software happens to be something designed from the ground-up to be portable between distros (or even OSes) in binary format. Packaging systems, for all their benefits, are to many non-technical users just one gigantic artificial barrier to ease of use. The Microsoft software installation model, for all its flaws, actually freaking works when it comes time to install something released after the OS install CD you have was shipped. Linux is the easiest OS in the world to use, so long as you only use it for the things the distro package set says you can.
December 5th, 2007 at 12:35 pm
That sounds about as good an idea as having . in my PATH.
December 5th, 2007 at 1:03 pm
That isn’t even close to the same thing, James. It’s like having /usr/lib in your ld.so.conf configuration. The JAR files would also only be included if the name of the file was listed in the target JAR file’s manifest, just like .so files are only linked in if the ELF file explicitly requests them.
The point is, I should be able to distribute a JAR file that can just list some standard/common JAR file as a dependency without having to encode OS-specific path information into the manifest or into a non-portable wrapper script.
Imagine if every binary on your system needed a wrapper like this:
#!/bin/sh
LD_LIBRARY_PATH=/lib:/usr/lib /bin/ld.so /usr/bin/myapp.bin
That’s what Java essentially requires for any app that goes outside of the (admittedly comprehensive) standard Java library.
December 6th, 2007 at 4:15 am
Right, I focused on the bit where it looked like you were distributing random jars into my path, vs /usr/bin/java just setting up the right environment variables. Having to set JAVA_HOME shits me to tears, so I fully support this.