org.jblas.util
Class LibraryLoader

java.lang.Object
  extended by org.jblas.util.LibraryLoader

public class LibraryLoader
extends java.lang.Object

Class which allows to load a dynamic file as resource (for example, from a jar-file)


Constructor Summary
LibraryLoader()
           
 
Method Summary
static java.lang.String fatJarLibraryPath(java.lang.String libname, java.lang.String linkage)
          Compute the path to the library.
 void loadLibrary(java.lang.String libname)
          Find the library libname as a resource, copy it to a tempfile and load it using System.load().
static java.lang.String unifyOSName(java.lang.String osname)
           
 
Methods inherited from class java.lang.Object
clone, equals, finalize, getClass, hashCode, notify, notifyAll, toString, wait, wait, wait
 

Constructor Detail

LibraryLoader

public LibraryLoader()
Method Detail

loadLibrary

public void loadLibrary(java.lang.String libname)
Find the library libname as a resource, copy it to a tempfile and load it using System.load(). The name of the library has to be the base name, it is mapped to the corresponding system name using System.mapLibraryName(). For example, the library "foo" is called "libfoo.so" under Linux and "foo.dll" under Windows, but you just have to pass "foo" the loadLibrary(). I'm not quite sure if this doesn't open all kinds of security holes. Any ideas?

Parameters:
libname - basename of the library
Throws:
java.lang.UnsatisfiedLinkError - if library cannot be founds

unifyOSName

public static java.lang.String unifyOSName(java.lang.String osname)

fatJarLibraryPath

public static java.lang.String fatJarLibraryPath(java.lang.String libname,
                                                 java.lang.String linkage)
Compute the path to the library. The path is basically "/" + os.name + "/" + os.arch + "/" + libname.



written by Mikio L. Braun and Johannes Schaback