maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stuart Maclean <stu...@apl.washington.edu>
Subject Re: JNI jars dependencies
Date Fri, 04 Jan 2013 20:34:02 GMT
Hi Martin, all,

the native code, either a .so or .dll, lives in the uber.jar at 
/META-INF/lib/.  We then link this in via wapmx's native loader:

import com.wapmx.nativeutils.jniloader.NativeLoader;

class LoadJNI {

static {
         String libName = "tsk4j";
         try {
             System.err.println( "Loading: " + libName );
             NativeLoader.loadLibrary( libName );
         } catch( IOException ioe ) {
             throw new ExceptionInInitializerError( ioe );
         }
     }
}

The NativeLoader will create ./tmplib and dump the .so in there and then 
call Java's regular loader.  So the only side-effect is the ./tmplib 
creation.  And I imagine you could register a deleteOnExit hook to even 
clean that up, I don't bother.

My LoadJNI class is essentially a dummy class purely to do the native 
load.  In classes where I actually HAVE native methods which are to be 
found in the .so, I force a class dependency:

class HasNatives {

void native foo();

static {
   LoadJNI dummy = new LoadJNI();
}

Short of multi-class-loader issues, this seems to work.  All of my 
classes which depend on the .so for their native are 'regular' classes 
with no fancy class loader things going on.

Any better ideas on how to ensure the .so loaded before any use would be 
welcomed.

Stuart



Stuart

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org


Mime
View raw message