|
Request For java.library.path Support in Fast MD5 Implementation in Java(TM)
Below is the email that I received from Fabio Strozzi requesting that support for the java.library.path system property be added to the Fast MD5 Implementation in Java. Fabio was kind enough to provide some code (below) to achieve this now on some platforms.Note that there already is fine grained control over where the native libraries can be located for the Fast MD5 Implementation in Java. The system property named com.twmacinta.util.MD5.NATIVE_LIB_FILE can be used to specify the exact path to be used for the file that contains the native library. Nevertheless, support for the java.library.path property would still be desirable because it is a standard mechanism now. Addition of support for this property is on the wish list.
Date: Sat, 1 Apr 2006 11:15:10 +0200 From: Fabio Strozzi To: Timothy W Macinta <twm@twmacinta.com> Subject: Suggestion regarding Fast MD5 Hi Timothy, I'm a student at the University of Bologna (Italy) and I used your fast md5 implementation for a class project (software engineering). Soon or later I'll publish it to sourceforge under GPL license. I used version 2.6 of fast-md5 but what I'm saying applies to 2.6.1 as well. I had to make some changes to your code since native libraries couldn't be used apart from the distribution directory tree. Clearly, I wanted to keep fast-md5 outside the project, with fast-md5.jar and MD5.so in separated directories: the former with all other jar files, the latter with system libraries (like many other java projects). As things are written, native libraries must stay in the classpath relative directory "lib/arch/linux_86" (suppose I'm using Linux). In fact: arch_lib_path = new File(new File(new File("lib"), "arch"), "linux_x86"); This is very uncomfortable 'cause it prevents native libraries to be used with the jar file most of the cases. I adjusted it with a temporary, unefficient solution that works for me, at least (starting from line 680 of MD5.java): if (os_name.equals("linux")) { if (os_arch.equals("x86") || os_arch.equals("i386") || os_arch.equals("i486") || os_arch.equals("i586") || os_arch.equals("i686") || os_arch.equals("amd64")) { StringTokenizer st = new StringTokenizer(System.getProperty("java.library.path"), System.getProperty("path.separator")); arch_libfile_suffix = ".so"; while (st.hasMoreTokens()) { String path = st.nextToken(); if (new File(path, "MD5.so").canRead()) { arch_lib_path = new File(path); break; } } } } Now, if I'd like to use the native libraries of fast-md5, I have to run the JVM with the argument: -Djava.library.path=/path/to/MD5.so/directory I think that the "lib/arch/linux_x86" directory can still be used as a default directory to look for MD5.so if none of the previous paths are good. Similar solutions can be written for Windows and Mac OSs too. As you see, I've added the amd64 arch option. I'm using an Athlon64 with 64 bit JVM as development environment: fast-md5 works fine even on this architecture. I hope this suggestion will be useful. Happy hacking -- Fabio.G.Strozzi - http://fstrozzi.web.cs.unibo.it
Java and all Java-based trademarks and logos are trademarks or registered trademarks of Sun Microsystems, Inc. in the U.S. and other countries.
All Pages, Images, and Other Content Copyright © 1997 - 2024 Timothy W Macinta , except where noted. All Rights Reserved. The "Tim Macinta Now" button may be used on web pages that are external to this site to provide a link back to this page. For usage guidelines on KMFMS artwork please see http://www.kmfms.com/usage-guide.html.