As already mentioned, in BS2000 there is no exact correspondence to the familiar shared objects from Unix systems. The characteristics essential to Java such as dynamic loading, the partitioning of name spaces and the dynamic determination of function addresses are mapped during the Java port. On the other hand, the naming property of multiple usage, the implicit loading of shared objects at program start and the subtleties of resolution cannot be mapped. This would require extension of the linking loader.
As the BS2000 linking loader cannot dynamically load any module from the POSIX file system, native methods must be created as LLMs and stored in PLAM libraries.
In the LLM there is no means of specifying a “list of required objects”, yet this functionality is necessary for Java and a search method analogous to Unix systems would appear to be useful in the POSIX file system. Hence, an additional description file has been implemented. This file contains what amounts to a description of a shared object. It is stored in the POSIX file system, observes the same naming conventions as shared libraries in Unix systems and contains all the information needed by Java in order to dynamically load and call the native methods.
This information comprises above all the PLAM library in which the LLM is stored, the name of the module (or modules) and, if appropriate, the list of required objects.
List of required objects
A list of required objects can be entered in the description file. These objects are dynamically loaded before the current object. Objects which already exist are not dynamically loaded again. Objects are identified by their POSIX file names.
These objects are included during loading of the current object to resolve external references.
It is perfectly possible for different shared objects to contain the same objects in their lists of required objects. The first reference to such an object then leads to dynamic loading
Name spaces (link contexts)
Each object is loaded in a separate link context. Objects are therefore partitioned in their name space.
The BS2000 linking loader now allows 200 link contexts. If more objects are loaded the application is aborted.
Search sequence
The search for shared objects (or rather, for the description files) operates in exactly the same way as in Unix systems, i.e. it is controlled through the environment variable LD_LIBRARY_PATH.
Resolution of external references
The contexts into which the required objects have been loaded are specified as reference contexts. The default context is used as reference context with the highest priority.
Searching through the share scope is explicitly prevented as it is not possible at the present time to see to it that this does not happen until after the reference contexts have been handled.
To resolve any unresolved external references, the system therefore initially searches through the default context and then through the required objects. All other objects are ignored.
This continues to be different from Unix systems. In particular, all external references in an LLM are shorted, so that no function in an LLM can be overwritten.