Incorporating native code in Java archive files

[0002] The present invention relates to a Java Virtual Machine adapted to load native code libraries stored in archived files.

[0003] JAVA (TM) applications are written as groups of classes, and typically execution of an application begins with the Java Virtual Machine (JVM) using a class loader to instantiate a main class, which in turn creates various objects requiring the instantiation of further classes. Class files are stored in various directory structures indicated by a classpath environmental parameter. In a stand-alone JVM, the class loader looks to classpath, an environmental parameter, which usually includes a sub-directory containing all the dedicated classes for a particular application, to determine where to look for classes. In a browser JVM, classpath also extends to the remote server from which an application (applet) is downloaded.

[0004] In an effort to cope with Java applications which have increased in complexity and so in size, it has become common for developers to package classes required for an application into one or more archived files, such as JAR files or ZIP files. Archived files are significantly more compact than their uncompressed component class files and so are particularly useful for deploying an application across a network, such as the Internet.

[0005] Archived files are stored in the directories of classpath or they can be individually designated within classpath. In the Figure, the classpath shown includes: a sub-directory structure in which class and archived files a to f are stored; and a direct reference to h.jar. When the JVM needs to instantiate a class, the class loader searches through the classpath directories, including class or archived files, and classpath archived files to find the required class file or to determine if such a class file is stored within an archived file. If a class is stored within an archive, as in the case of classes db and dc, then the JVM uncompresses the class file from the archive directly into memory. Thus, the unarchived classes are not written to disk and, in the case of network applications, far less time is lost uncompressing the file than downloading an uncompressed class from a remote server.

[0006] Although, Java provides a means for developing applications in a platform independent manner, some application developers nonetheless either need or find it easier to use native code. In the case of Java applications written for the MICROSOFT WINDOWS™ suite of platforms, such native code typically comprises dynamic link libraries (DLLs) accessed through the Java Native Interface (JNI).

[0007] When an application employs native functionality, it should indicate this to the JVM before calling such methods by calling the loadLibrary method on either the java.lang.System or java.lang.Runtime object. Alternatively, the JVM can call the loadLibrary method in response to a native method call to a library which has not been loaded. In any case, loadLibrary operates in the same manner. The loadLibrary method is passed a string comprising the name of the native code library to be loaded. Although implementation specific, generally the method then searches through a library path (analogous to classpath) for the appropriate library. In the Figure, the library path includes a sub-directory structure including DLLs aa to cc and a cache sub-directory whose purpose will be explained later. On finding a library, it is loaded into memory and its methods, for example, methods bba . . . bbc from library bb.dll, become exposed for use within the Java application.

[0008] While this functionality in itself is quite useful, it does means that library files must be available to the JVM, in the same manner as to platform dependent applications, before applications availing of such libraries are executed. This does not pose a problem where default native code libraries are accessed, but more and more developers are implementing applications partially in Java and partially in native format. This means that for network applications, in particular, the native libraries must be installed before the network application can execute, and this places a high deployment cost on such applications.

[0009] There has been a clamour from developers seeking to place native code in archived files, for example, d.jar, which could then be deployed with the classes comprising the remainder of the Java application. This would mean that Java applications could be deployed and updated in a single step as they are required by users, thus making the functionality of native code more accessible to both developers and users.

[0010] Notwithstanding, this functionality has not been made available to date in a Java Virtual Machine.

[0011] The present invention, however, provides a Java Virtual Machine according to a Java virtual Machine comprising: means, responsive to a request to instantiate a class, for searching a first path in which class files and archived files are stored; means, responsive to locating a requested class file in said first path or within an archived file in said first path, for loading said class into memory; means, responsive to a request to load a native code library, for searching a second path in which library files are stored; means, responsive to locating a requested library file in said second path, for loading said library into memory; wherein said means for searching a second path is adapted to search said first path; and in that said means for loading a library is responsive to locating a requested library file in an archived file in said first path to load said library into memory.

[0012] It will be seen that in spite of adapting the JVM to include the platform dependent functionality of the invention, whereby archived files may include native code, the JVM is no more platform dependent than conventional JVM's, which allow applications to make native method calls.

[0013] Embodiments of the invention will now be described with reference to the accompanying drawing which is a schematic diagram illustrating a classpath and a library path used by a Java Virtual Machine.

[0014] Referring now to FIG. 1, a stand-alone JVM is set up on a machine running on any platform. A library path (LIBPATH) is defined which points to one or more directories on the hard drive where required native code libraries can be found—in this case DLLs aa to cc. A class path (CLASSPATH) is defined to point to a list of locations where class files can be found—in this case a sub-directory structure comprising files a to f and an explicit designation of archived file h.jar. Nonetheless, it should be seen that the invention is not limited to a stand-alone JVM and could equally apply to a browser JVM. The invention is also applicable to native code libraries for any platform, not necessarily those of Microsoft.

[0015] A conventional JVM normally has two sets of routines, one for loading native code libraries from the library path and a second for loading class files from classpath. The second mechanism is also used to load property files and other data files used by Java code.

[0016] According to the invention, the conventional native code library load mechanism, ie loadLibrary, is augmented to search the classpath for the required library (this could be before, after or during the conventional search of the library path).

[0017] Where the JVM operates on a Microsoft platform, the search identifies the correct DLL by its name, in this case, da.dll. Preferably, the name includes a platform specific component (possibly a suffix for example “.NT”, “.AIX”, “.OS2”, “.OS390”). Thus, the JVM, which knows which platform it is running on, can decide if a DLL whose name, excluding the suffix, matches that passed by the application to the loadLibrary method is suitable for the JVM's platform. This means that an application can make call “System.loadLibrary(X.dll)”, but that more than one version of X.dll, eg X.dll.NT and X.dll.OS2, is included in an archived file. A Microsoft JVM will ignore X.dll.OS2 if it is detected first in a search and can decide which DLL it is willing to load based on the DLLs suffix platform designation.

[0018] This also means that the file names need to be correctly set when the application (of which the library forms a part) is packaged. This can be done manually or the integrated development environment (IDE), for example, IBM's Visual Age for Java, within which such applications are typically developed, needs to be adapted to package native code with the correct file names.

[0019] In a first embodiment, the library path includes a cache sub-directory If the required native code library is found and it is inside an archived file, for example, the search detects that da.dll is stored within d.jar, the library is extracted from the archived file and copied to the cache sub-directory.

[0020] It should be seen that if the archived file containing native code had been explicitly decompressed by a user, then the search would directly detect the DLL in the classpath sub-directory into which the archived file was decompressed. If such a DLL is found, it is copied directly to the cache sub-directory.

[0021] Once the DLL had been placed in the cache directory, loadLibrary can continue in the conventional manner, using its normal resolution and loading mechanism to load the library from the cache directory.

[0022] Preferably, the cache directory is only used by the JVM for libraries extracted from archived files. The JVM can further detect once the operating system has released such libraries and so can delete such libraries from the cache so as to prevent possible conflicts when other applications execute.

[0023] The advantage of the first embodiment is that the changes to the JVM are minimal. The operating system provided functions for loading and resolving DLL functions can still be used and the embodiment easily extended to any platform which supports DLLs or that operates equivalently.

[0024] The disadvantages of the first embodiment are that the existence of the libraries is externalised and that moving the library from the archived file to the hard drive, then loading it from the hard drive into memory is not the most efficient approach.

[0025] In a second embodiment, the native code library loading mechanism is again augmented to search classpath for the required library. However, once the library is found, either directly or within an archived file, the JVM loads the library directly into memory, without writing the library to disk, in a manner similar to the way in which class files are loaded directly into memory.

[0026] It will be seen, however, that even conventional direct loading of native code libraries into memory is platform dependent and as such the JVM for each platform needs to take into account such differences when extracting the library from an archive directly into memory.

[0027] Although more complex to implement, the advantages of the second embodiment are that it is quicker than the first embodiment and hidden from the user.

[0028] It should be noted that classpath and the library path need not be mutually exclusive. The invention is directed towards searching the archived files normally used by a Java application to store compressed classes to determine if such archived files include required native code libraries.