[prev in list] [next in list] [prev in thread] [next in thread]
List: rxtx
Subject: Re: [Rxtx] LibraryLoader
From: Trent Jarvi <tjarvi () qbang ! org>
Date: 2012-06-08 4:15:19
Message-ID: alpine.LFD.2.00.1206072213230.23689 () rxtx ! qbang ! org
[Download RAW message or body]
OK. I'll put something together and post it to the list if nobody beats
me to it. I see there are som LGPL examples like 7zip doing just that.
On Thu, 7 Jun 2012, Gregg Wonderly wrote:
> Please do not use LoadLibrary, at all. Instead, all JNI libraries should be \
> included in the jar, and it should look at System.getProperties() values to decide \
> which library is appropriate, and then it should copy that library to a "temp" \
> directory using File class facilities. Finally, System.load() should be used to \
> load the code from that temporary directory.
> There can then be a system property that specifies which library to load, \
> explicitly, as a file path name. This will facilitate cross platform testing and \
> development.
> LoadLibrary should really only be used by native Java facilities that need JNI \
> support. Anytime you do JNI for an add-on library, it really is better to use \
> System.load() so that you can dynamically manage the library, and so that the \
> library can be part of the jar to help with versioning and other details related to \
> trying a specific version of RxTx.
> Gregg Wonderly
>
> On Jun 7, 2012, at 10:19 AM, Trent Jarvi wrote:
>
> >
> > We can do something like the following initially to remain comptatible with \
> > applications currently working:
> > if("true".equals(System.getProperty("gnu.io.rxtx.LibraryLoader"))) {
> > LibraryLoader.loadLibrary( "rxtxSerial" );
> > } else {
> > System.loadLibrary( "rxtxSerial" );
> > }
> >
> > The LibraryLoader would need considerable cleanup for 64 bit support, intel \
> > solaris and others before being ready for general use.
> > On Thu, 7 Jun 2012, Alexander Graf wrote:
> >
> > > Hi Trend,
> > > I think the idea is good, but this might have side effects in software which \
> > > can distinguish between different binaries itself. What I mean are for example \
> > > library wrapper modules for netbeans platform. They are using a directory tree \
> > > to locate the library for the actual platform:
> > > modules/lib/<arch>/<os>/
> > >
> > > (See: http://bits.netbeans.org/dev/javadoc/org-openide-modules/org/openide/modules/doc-files/api.html#jni)
> > >
> > > This technique assumes the same base name for all lib variants. However, for \
> > > the special case "Netbeans Platform" this should work because their loader is \
> > > looking in the
> > > modules/lib/
> > >
> > > directory first (independently from arch/os). For rxtx all lib variants with \
> > > different suffixes could be in this directory.
> > > Maybe there are other rich client platforms with similar behavior where no \
> > > workaround exists. For these platforms should exist some alternative which \
> > > loads the library without any suffix as it always was.
> > > Regards
> > > Alex
> > >
> > > On Wed, 06 Jun 2012 16:29:51 +0200, Trent Jarvi <tjarvi@qbang.org> wrote:
> > >
> > > > As I'm going through various patches, I came accrossed a LibraryLoader some \
> > > > use with rxtx. The code is below. I'm curious about any feedback concerning \
> > > > adding it to the next release. The patch allows libararies to have a suffix \
> > > > and not cause conflicts with mulitple libraries in the same directory. I \
> > > > think thats the last patch from ben's rxtx bitbucket thats usable at this \
> > > > point. https://bitbucket.org/ivertex/rxtx
> > > > public class LibraryLoader {
> > > > private static final String librarySuffix;
> > > >
> > > > static {
> > > > String osName = System.getProperty("os.name");
> > > > String osArch = System.getProperty("os.arch");
> > > >
> > > > if (osName.equals("Windows 95") ||
> > > > osName.equals("Windows 98") ||
> > > > osName.equals("Windows Me") ||
> > > > osName.equals("Windows NT") ||
> > > > osName.equals("Windows NT (unknown)") || // Vista on Java 1.4
> > > > osName.equals("Windows Vista") || // Vista on newer Java
> > > > osName.equals("Windows XP") ||
> > > > osName.equals("Windows 2000") ||
> > > > osName.equals("Windows 2003")) {
> > > > // Windows needs no suffix, the dlls can be loaded
> > > > librarySuffix = "";
> > > > } else if (osName.equals("Mac OS X")) {
> > > > // Check for different Mac OS X versions is not necessary as all versions
> > > > // (i836, x86_64, and ppc) are in the universal binary
> > > > librarySuffix = "-mac-universal";
> > > > } else if (osName.equals("Linux")) {
> > > > if (osArch.equals("x86") || osArch.equals("i386") ||
> > > > osArch.equals("i486") || osArch.equals("i586") ||
> > > > osArch.equals("i686") )
> > > > librarySuffix = "-linux-x86-32";
> > > > // NOTE: Java's os.arch property is a bit of a misnomer, fortunately for us. \
> > > > The // 32 vs. 64 bit library selection decision must based on what JVM we're \
> > > > running // in and not on the host OS's architecture. If we're running 32-bit \
> > > > Java on a // 64-bit Linux OS then we should still use 32-bit shared library. \
> > > > Luckily for us, // the os.arch property is what the JVM is and not what the \
> > > > OS is. else if (osArch.equals("x86_64") || osArch.equals("amd64"))
> > > > librarySuffix = "-linux-x86-64";
> > > > else
> > > > // Unknown linux architecture, assume 32 bit.
> > > > librarySuffix = "-linux-x86-32";
> > > > } else if (osName.equals("Solaris") || osName.equals("SunOS")) {
> > > > if (osArch.equals("sparc"))
> > > > librarySuffix = "-solaris-sparc-32";
> > > > else
> > > > // Unkown solarix arch
> > > > librarySuffix = "-solaris-sparc-32";
> > > > } else {
> > > >
> > > > // Unknown os/arch
> > > > librarySuffix = "";
> > > > }
> > > >
> > > > }
> > > >
> > > > /**
> > > > * Load the given library with the detected suffix.
> > > > */
> > > > public static void loadLibrary(String libraryName) {
> > > > System.loadLibrary(libraryName + librarySuffix);
> > > > }
> > > > }
> > > > --
> > > > Trent Jarvi
> > > > tjarvi@qbang.org
> > > > _______________________________________________
> > > > Rxtx mailing list
> > > > Rxtx@qbang.org
> > > > http://mailman.qbang.org/mailman/listinfo/rxtx
> > > _______________________________________________
> > > Rxtx mailing list
> > > Rxtx@qbang.org
> > > http://mailman.qbang.org/mailman/listinfo/rxtx
> > _______________________________________________
> > Rxtx mailing list
> > Rxtx@qbang.org
> > http://mailman.qbang.org/mailman/listinfo/rxtx
>
> _______________________________________________
> Rxtx mailing list
> Rxtx@qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx
>
_______________________________________________
Rxtx mailing list
Rxtx@qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic