For reducing the communication overhead the default class loading is delegated to the parent class loader, which loads classes from the local file system.
The adaptation loader has access to the list of all implementation classes. If an implementation class is requested by the mobile code the loader contacts the repository via the local repository client.
The loader of the prototype is also able to load dynamic libraries which are necessary for the support of the Java Native Interface (JNI) [#!Li1999!#]. The JNI supports the execution of native code from Java programs. E.g. this is necessary in order to access the Windows registry, the central configuration database for Windows applications. In the example of the browser configuration the access to the registry is necessary to determine the default web browser and to configure the IExplorer.
The native functions must be compiled and linked into a dynamic shared library, e.g. a DLL for Windows. During the execution of the Java program the library is dynamically linked to the Java program. Before the library is linked to the program the findLibrary() method of the loader is invoked by the Java interpreter. It returns the absolute path name of the dynamic library. The loader contacts the repository through the repository client and stores the dynamic library in a temporary directory.
This implementation works fine for the prototype, but the writing of the library to the temporary directory slows down the adaptation procedure.