MetaJava

The adaptation of runtime mechanisms is discussed in [#!GoKl1997!#] and a platform for adaptable operating system mechanisms, called MetaJava , is presented. MetaJava provides reflection for controlling the execution environment of an application. The behavioral reflection is different from the Java Reflection which is denoted in [#!GoKl1997!#] as structural reflection. Another aspect of MetaJava is the separation of functional code and non-functional code, called metaprogramming . The functional code, which concerns the computation of the application, resides in the base level and the non-functional code, which controls objects in the base level, resides in the meta level (s. fig. ).

 

Figure: Behavioral reflection and reification  

Whereas in traditional systems ad hoc extensions of the programming language support multiple threading, distribution, fault tolerance, mobile objects, etc., MetaJava hides such functionality in the meta level.

For instance, Java supports the programming of multi threads or Remote Method Invocation, but the programming is done on the same level as the programming of the application task which might be independent from the thread management or object distribution.

For triggering the meta level reification is necessary. Reification is defined in [#!GoKl1997!#] as ``the process of making something explicit that is normally not part of the language or programming model''. The reification is realized using events that are raised by the base level and delivered to the meta level. For using the meta level a meta object must be attached to an object in the base level. Meta objects can be attached to references, objects and classes.

An application for MetaJava is for example a special type of remote method invocation where instead of the Java build-in RMI package a proprietary mechanism implements remote method invocation over a proprietary protocol stack.

If a method of a remote object is called, an event of the local method call of the proxy object is delivered to the attached meta object. The meta object then propagates the method invocation to the server.

In the context of adaptation an event for class loading might be used in order to initiate the adaptation mechanism and to select the right class for the current environment.

For the integration of MetaJava a modified Java Virtual Machine (JVM), the MetaJava Java Virtual Machine (MJVM), is used. The MJVM uses the same class file format and byte code set as the JVM, but provides a meta-level interface (MLI) permitting the meta objects to access the internal state of the virtual machine.

This implementation implies that the deployment of MetaJava based applications is constrained to hosts on which a MJVM is installed.

MetaJava could provide the architecture for a dynamic adaptation mechanism. The adaptation is executed in the meta level hidden to the application. But the constraint of a MJVM contradicts especially in particular requirement R6 because the assumption to install everywhere a MJVM limits the radius of the mobile code to such configured environments. The dynamic adaptation would limit the mobility of the code. Therefore MetaJava seems not to be the best technology for dynamic adaptation.