Auto-loading the correct libraries for an OS, sans applet

[ztellman]

I apologize if this is a stupid question or a re-tread of old material.  My understanding of Java as a platform is remedial at best, but I couldn't find anything that seems to deal with this issue.

Over the past few months I've been working on Penumbra, which is a wrapper for JOGL written in Clojure.  Some examples can be found here.  Everything works great, but setup for new developers is a tremendous hassle.  I've put jars and libraries for every platform in /lib, and anyone cloning the repository then has to go through a lengthy process of setting up their class and library paths, which can be fraught with typos and irritation.

As I understand it, when a JOGL applet is loaded via JNLP, the correct jars and libraries are identified and downloaded, right then and there.  Is there some reason I can't leverage this same mechanism for loading the files onto a developer's system when they initialize the library?  If not, why not?  Any responses are greatly appreciated.

[pjt33]

As I understand it, when a JOGL applet is loaded via JNLP, the correct jars and libraries are identified and downloaded, right then and there.  Is there some reason I can't leverage this same mechanism for loading the files onto a developer's system when they initialize the library?  If not, why not?  Any responses are greatly appreciated.

If you mean at runtime then of course you can use Webstart (JNLP). It supports applications better than applets.

If you mean at compile-time then one option would be to use ant.

1   2   3   4   5   6   7   8   9   10   11   12   13   14   15   16   17   18   19   20   21   22   23   24   25   26   27   28   29   30   31   32   33   34   35   36   37   38   39

<condition property="_nativeLibsDir" value="${lib}/OS-X">          <os family="mac"/>       </condition>       <condition property="_nativeLibsDir" value="${lib}/Linux32">          <and>             <os family="unix" arch="i386"/>             <not>                <os family="mac"/>             </not>          </and>       </condition>       <condition property="_nativeLibsDir" value="${lib}/Linux64">          <and>             <os family="unix" arch="amd64"/>             <not>                <os family="mac"/>             </not>          </and>       </condition>       <condition property="_nativeLibsDir" value="${lib}/Win32">          <os family="windows" arch="i386"/>       </condition>       <condition property="_nativeLibsDir" value="${lib}/Win64">          <os family="windows" arch="amd64"/>       </condition>       <!-- HACK! -->       <path id="native.libs.path">          <pathelement location="${_nativeLibsDir}" />       </path>       <property name="nativeLibsDir" refid="native.libs.path" />       <path id="clspath">          <fileset dir="${lib}">             <include name="*.jar" />          </fileset>          <fileset dir="${nativeLibsDir}">             <include name="*.jar" />          </fileset>       </path>

For compilation including it in the classpath is enough. To run it you need in addition

1	<jvmarg value="-Djava.library.path=${nativeLibsDir}" />

[jdp]

Hi,

I have a solution that works for many applications.. a JNLP Loader @ http://code.google.com/p/jnlp-loader

The idea is to package the application main JNLP with the loader code into a JAR. 

Running the JAR unpacks the application described by the JNLP and then runs it.

There's a couple issues with this approach.  First, it's insecure, like any executable native code.  Second, it's purposefully not using any graphics because I'm using it with NEWT and don't want to load AWT. 

This second point can be dealt with if there's any demand for it -- AWT applications can let jnlp-loader use AWT, and non-AWT users can use it as is with the long wait for unpacking to complete and then use AWT for any errors.  Another, third issue is that it's currently not detecting java runtime version and doing anything with that.  The present version is simply compiled for 1.5, and proceeds to run the application if it can.

I think the best use of this approach is in development, or for applications in the neighborhood of the technically inclined (and patient).  I mean, applications using this as is want to tell folks that it requires java 1.5 and runs silently until the downloading and unpacking completes, which can be a minute or two on a fast connection.

I have a JOGL/NEWT Gears demo @ http://fv3tk.googlecode.com/svn/web/fv3tk-gears-loader-0.0.1.jar


Best wishes,
John