When you call
System.loadLibrary("foo") Java tries to load
libfoo.so. That's actually sensible behavior, but
unfortunately the error message doesn't tell you what file
it's trying to load. It just says:
Exception in thread "main" java.lang.UnsatisfiedLinkError: no foo in java.library.pathWhich doesn't actually help that much if you've forgotten to put "lib" in front of your file name.
Welcome to non-Windows. It gets even worse when you start dealing with libfoo.so.2 and libfoo.so.2.0.0.
As far as DLL hell goes, non-Windows has got nuthin' on Windows. One thing is better that I'll grant -- having multiple revisions of the same library is at least possible in a non-hackish way (that is, if your code needs libfoo.so.1 and some other code needs libfoo.so.2 you can put them in the same directory and things work as you expect).
So as much as I don't like it, I do see some of the reasons. It does take getting used to. The JNI just ends up passing the library name to dlopen(3) on non-Windows, so it doesn't even realize that it's getting mangled at the lowest level.
On OS X it's even worse -- they use .dylib for their dynamic libraries EXCEPT when they're JNI extensions, where they use .jnilib for the file extension. Sigh.
One small thing to be happy about with this scheme in Java -- the parameter to loadLibrary doesn't have to change for every platform. It gets mangled into the appropriate platform filename.