Is there a standard place to install java class libraries?

[Joe Areeda]

Hi,

One of the projects I work on is a client server package that implements a proprietary protocol (sic). The client is a set of applications and a library to support development. We use SWIG to wrap the library for Java, Python, Matlab and Octave. We package this as RPM, DEB, MacPorts and a Windows installer.

For C/C++, Python and Octave there are standard locations for the libraries. So there's nothing special the users need to do to use them.

Java and Matlab (which uses java with weird return types) I don't think such a place is defined. I hope I'm wrong.

It's not a big deal to force people to set a classpath, but it would be nice if they didn't have to. We could even set it on install, I suppose.

Thanks,
Joe

[Stephan van Hulst]

You could have the installer ask for java runtimes to install the library for, and then add the library to the runtime's lib/ext folder. Your library will automatically be on the classpath for that runtime.

[Joe Areeda]

Thanks Stefan,

It took a while to research your suggestion.

I don't think it's optimal for our needs. Many of our systems have multiple Java versions installed plus Matlab (to my endless frustration) installs its own. We test this stuff with 1.6-1.8 and so far no problems.

Right now the best option I can come up with is to have the installer set the CLASSPATH variable system wide, which will work for everything but Matlab.

Best,
Joe

[Campbell Ritchie]

Joe Areeda wrote: . . . Right now the best option I can come up with is to have the installer set the CLASSPATH variable system wide, . . .

Please explain more. Setting a system CLASSPATH usually does more harm than good.

[Joe Areeda]

Campbell Ritchie wrote:]Please explain more. Setting a system CLASSPATH usually does more harm than good.

CRAP!

Now I have to rethink the whole thing.

My problem is how to disbute a c;ass libraty that a lot of things depend on in an environment that is, let's just say.mpt Java centric.

Most languages C/C+=, Python (their favorite),and Octave (fringe at best) just work.

Java and Matlab (based on java) require unique and fragile code to find the libraries.

Please help me find a better option to CLASPATH.

Best,
Joe

[Stephan van Hulst]

I really don't understand what kind of architecture would lead these applications to be able to use the API that your library implements, while omitting a way to configure the plugin locations.

If these applications were compiled by you, but you don't include the library in each individual distribution to link against, this is BAD.

Setting a global classpath is WORSE.

[Joe Areeda]

Hi Stephan,

I am open to suggestion but honestly I have not come up with a good solution, everything I can think of sucks one way or the other. Excuse me while I describe the problem and muddle my way through the options we've considered so far.

One group I work in maintains a cross platform client/server application with a C library supplying the API. There is a C++ wrapper that was written to facilitate SWIG bindings for Python, Java, Matlab and Octave. The utilities and libraries are packaged for Scientific linux 6 and 7, Debian 7 & 8, ubuntu 12.04 LTS and 14.04 LTS, MacOs 9 &10 and Windows 7.

For C/C++, Python and Octave the packages are all installed in a standard location like /usr/lib64, /usr/lib64/python2.x/site-packages,/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7. C/C++ apps that use the libraries are built and packaged for each OS.

Python and Octave applications are independent of API libraries and just find them automatically.

The Java class library has several classes and a JNI shared object (.so, .dyld, .dll).

One thought is to package the classes in a jar and install the shared object in the standard location. If I include the jar in my app we have the version mismatch problem. So we can add code to check versions when we load the library. That was my favorite.

Another way to do it is to install the jar and native libraries someplace standard but the only sort of standard places are all dependent on the jre installation. Hence the global classpath hack. The only problem I see with this one is new libraries that are not backwards compatible. That is a very very rare occurrence. The blow back is significant and many people just refuse to upgrade meaning the developers have to maintain 2 versions.

One person suggested we put all the shared objects into one jar file but that is a packaging nightmare as the packages are maintained by different people (OS specialists) and many are on nightly build and test systems.

It is also worth mentioning that the applications that use these libraries are separate they are developed completely independent of this project. For example I maintain a Matlab app that uses these libraries. In their current form they are installed in /usr/lib64/java on Linux as .class and .so files. I know, I can't think of a worse way to do it. What the Matlab app has to do is figure out which OS it's running on, find the installation and set up the java path on startup.

I've been searching the web for the way others solve this without luck. If you know of a cross platform library with native code that addresses this problem, I'd love to study how they do it.

Best,
Joe

[Joe Areeda]

Stephan van Hulst wrote:I really don't understand what kind of architecture would lead these applications to be able to use the API that your library implements, while omitting a way to configure the plugin locations.

If these applications were compiled by you, but you don't include the library in each individual distribution to link against, this is BAD.

Setting a global classpath is WORSE.

Configuring the plugin locations is an interesting concept and perhaps what gets set on installation is not a global classpath but a different environment variable that is only used by this library.

A little more background. The library is a network data service that has multiple servers around the world and serves pieces of a 2PB store of science data to users for analysis and display.

The applications that use it are written by scientists and programmers. The science guys are mostly Pythonic, or Matlabian. I'm probably the biggest Java user although I do have C++, python and matab projects to maintain.

For the python stuff, users can download a .py file and run it on any system with the proper libraries installed.

For java it's not just java -jar myLittlePlot.jar but a wrapper script that figures out what OS your running on and figure out how to find the libraries the run java -cp ${libLoc} -jar myLittlePlot.jar.

It's that wrapper script that I want to replace.

Joe

[Stephan van Hulst]

Joe Areeda wrote:It is also worth mentioning that the applications that use these libraries are separate they are developed completely independent of this project. For example I maintain a Matlab app that uses these libraries. In their current form they are installed in /usr/lib64/java on Linux as .class and .so files. I know, I can't think of a worse way to do it. What the Matlab app has to do is figure out which OS it's running on, find the installation and set up the java path on startup.

This is the crux. Every application has a designer that chose to use the API. It's the designer's responsibility to include a way to locate the implementation. This scales just fine, because adding a JVM argument to the application launcher is a really trivial bit of work when you compare it to the application using the API at all. I believe you can even add entries to the classpath in Matlab dynamically. You can even let the application find your library from a custom environment variable, if you so please.

To summarize: Let every application handle it individually is the neat, robust way to go, even if it requires a bit of extra work. Using CLASSPATH will be easy, but will lead to Jar Hell.

[Stephan van Hulst]

Joe Areeda wrote:For java it's not just java -jar myLittlePlot.jar but a wrapper script that figures out what OS your running on and figure out how to find the libraries the run java -cp ${libLoc} -jar myLittlePlot.jar.

I don't believe -cp and -jar work very well in conjunction. Anyway, consider shipping the application with a shortcut fit for the OS (or shotgun all the shortcuts). For windows, the target should be java -cp myLittlePlot.jar;%MYLIB_HOME%\mylib.jar my.little.plot.Main.

[Joe Areeda]

Stephan van Hulst wrote:I don't believe -cp and -jar work very well in conjunction. Anyway, consider shipping the application with a shortcut fit for the OS (or shotgun all the shortcuts). For windows, the target should be java -cp myLittlePlot.jar;%MYLIB_HOME%\mylib.jar my.little.plot.Main.

Thanks Stephan!

I think that's about as good as we can do.

Best,
Joe