<<< Timothy W Macinta's Website Menu >>>
Home | My Java | Resume/CV | R&D | Age Detector | Contact
Timothy W Macinta - Contract Software Development

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);
    Now, if I'd like to use the native libraries of fast-md5, I have to run the JVM
    with the argument:
    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
    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 - 2017 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.