Browse Prior Art Database

Dynamic Java Native Interface Code Extraction Disclosure Number: IPCOM000020414D
Original Publication Date: 2003-Nov-20
Included in the Prior Art Database: 2003-Nov-20
Document File: 3 page(s) / 11K

Publishing Venue



Java provides a way to write code once and run it on different systems. Unfortunatelly, it does not provide all the functions needed in some advanced applications, like trying to ping an IP address. In those cases, the developer has to rely on native code (code written for the specific operating system) to achieve the desired goal. This introduces several complications and restrictions: - problems to upgrade the native code dynamically (without restarting the Java Virtual Machine - JVM for short) - native code can only be loaded once in the JVM if multiple ClassLoaders are being used and it can only be at one version - installation and deployment gets more complicated due to the added native code and operating system dependency Disclosed here is an algorithm to solve the issues above, specifically on a distrubed system which needs to be highly available.

This text was extracted from a PDF file.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 93% of the total text.

Page 1 of 3

Dynamic Java Native Interface Code Extraction

Java provides an Application Programming Interface (API) that allows application code to return the location of native code before the default behavior takes place. This requires the application to use a special Java Classloader to bootstrap itself and to load any components of the system. This ClassLoader is called when a native library needs to be loaded and provides the necessary hook to solve the problems with the default implementation.

Flow for solving the problem:


Page 2 of 3

Explanation about the chart: - findLibrary is the ClassLoader method called to return the file system location of the native library to be loaded. The library name is not decorated at this point ("ping" for example) - map library name will convert the name passed to findLibrary to the system appropriate name ("ping.dll", "libping.a", "") and append any prefixes needed by the system in use. This allows the library code to be packaged within the Java Archive (JAR file) of the code using the native library. - extract library will extract the library code from the archive and write it to the filesystem, with a unique name based on the library name and instance of the ClassLoader being used. This avoids the limitation of single version, load once problem. - if the library has any dependencies, they will be extracted as well


[This page contains 1 picture or other non-text object]

Page 3 of 3

- the file system location of the extrac...