MetaJava: An Efficient Run-Time Meta Architecture for Java™ Jürgen Kleinöder1, Michael Golm University of Erlangen-Nürnberg, Dept. of Computer Science IV Martensstr. 1, D-91058 Erlangen, Germany {kleinoeder, golm}@informatik.uni-erlangen.de Abstract form of libraries. This approach has the advantage of being 1 user customizable but it is not transparent to the functional Adaptability to special requirements of applications is a 2 code of the application program. crucial concern of modern operating system architectures. We advocate a reflective software architecture to over- Reflection and meta objects are means to achieve this come these deficits while retaining customizability and adaptability. This paper reports on ideas and experience we transparency. obtained while extending the run-time system of the object- We use Java as our target system and call the extended oriented language Java with reflective capabilities. system MetaJava. Nevertheless our principles may be used We explain our model of an object-oriented architecture to equip other systems with reflective capabilities. that allows flexible and selective attachment of reflective We are aware that we must impose some constraints to properties to objects. We show how reflection can be make our extension attractive to a large community of Java obtained with minimal changes to the existing system and users. So we avoided changes to the compiler and the virtual how the penalty in run-time performance can be minimized. machine. We merely added extensions to the virtual machine. Our architecture is not limited to special application Section 2 introduces reflection and metaprogramming. domains like distributed or concurrent computing but can Section 3 describes our computational model. Section 4 pre- also be used to support different security policies, just–in- sents the design and implementation. Section 5 outlines time compilation, location control of mobile objects, etc. As some examples. We conclude with a comparison with an example, a remote method invocation mechanism is related work and a short note about the current project status described to demonstrate how the Java programming model and future work in sections 6 and 7. can be enhanced using our meta architecture. 2 Reflection and metaprogramming 1 Introduction In the past programs had to fulfil a task in a limited com- putational domain. Demands of today’s applications are Today’s applications demand more flexible support from becoming more complex: multithreading (synchronization, operating systems (OS) for a variety of tasks and run-time deadlock detection, etc.), distribution, fault tolerance, properties, including distribution, security, persistence, mobile objects, extended transaction models, persistence, fault tolerance, and synchronization. The OS should pro- and so on. These demands make it necessary for an applica- vide these services in a transparent way, so that application tion program to observe and adjust its own behavior. Many programs do not need to be modified if new or different run- ad hoc extensions to languages and run-time systems have time properties are required. One approach to providing this been implemented to support features such as persistence. support is to extend the OS for the required services as was Reflection is a fundamental concept for a uniform imple- done for fault tolerance in Delta [7] or for persistence in the mentation of all these different demands. Grasshopper Kernel [15]. This strategy has some deficien- According to Maes [18], reflection is the capability of a cies. It is neither user customizable nor extendible. A sec- computational system to “reason about and act upon itself” ond approach is to provide the required functionality in the and adjust itself to changing conditions. Metaprogramming separates functional from non-functional code. Functional 1. This work is supported by the Deutsche Forschungsgemeinschaft code is concerned with computations about the applica- DFG Grant Sonderforschungsbereich SFB 182, Project B2. 2. When we talk about operating systems we include system libraries, tion’s domain (base level), non-functional code resides at run-time systems, and virtual machines. the meta level, supervising the execution of the functional code. To enable this supervision, some aspects of the base- meta system level computation must be reified. Reification is the process attached to a of making something explicit that is normally not part of the group of objects language or programming model. event (reification) meta obj. As pointed out in [9] there are two types of reflection: structural and behavioral reflection (in [9] termed computa- reflection tional reflection). Structural reflection reifies structural aspects of a program, such as inheritance and data types. A common technique for structural reflection is to let one base system meta class control a number of base classes. Run-Time Type Identification (RTTI) of C++ [25] is an example of struc- tural reflection. Behavioral reflection is concerned with the reification of computations and their behavior. Our architec- attached ture deals with behavioral reflection at run time. We show to a reference how a run-time meta architecture can be built that is nearly meta system as efficient as one that operates only at compile time. A pro- meta obj. gramming environment that incorporates a meta architec- ture gains the following advantages: Figure 1: Computational model of behavioral reflection Increased productivity. Like object-oriented program- ming, metaprogramming is a new paradigm which leads to more structured and easily maintainable programs. 3 Computational model Separation of concerns. In conventional programming the application program is mixed with and complicated by pol- Traditional systems consist of an operating system and, icy algorithms. This makes it difficult to understand, main- on top of it, a program which exploits the OS services using tain, debug, and validate the program. an application programmer interface (API). Separation of the reflective from the base algorithm Our reflective approach is different. The system consists makes reusability of policies feasible [11], [14]. The use of of the OS, the application program (the base system), and a separate meta space allows the application programmer to the meta system. The program may not be aware of the meta focus on the application domain. The additional functional- system. The computation in the base system raises events ity is supplied as a library of meta components or is devel- (see Figure 1). These events are delivered to the meta sys- oped together with the application program. We regard tem. The meta system evaluates the events and reacts in a reflective decomposition as a new structuring technique in specific manner. All events are handled synchronously. addition to functional and object-oriented decomposition. Base-level computation is suspended while the meta object processes the event. This gives the meta level complete con- Configurability. The meta level establishes an open system trol over the activity in the base system. For instance, if the architecture [13]. New policies can be implemented without meta object receives a method-enter event, the default changing the application code. This is especially useful for behavior would be to execute the method. But the meta class libraries, where the library designer can only guess the object could also synchronize the method execution with demands of the library user. another method of the base object. Other alternatives would Not only application developers can profit from metapro- be to queue the method for delayed execution and return to gramming but also application users may replace meta com- the caller immediately, or to execute the method on a differ- ponents to tailor the application to their particular needs. ent host. What actually happens depends entirely on the Typically, a system administrator will tailor the meta space, meta object used. so that the application can take care of local resources such In our current implementation a computation only raises as processors, printers, network connections, or hard disks. an event if one of its methods is called. We plan to include Transparency. Transparency and orthogonality of base more event types in a later version of MetaJava. One could system and meta system are desirable features but cannot imagine events for outgoing method calls, variable accesses always be guaranteed in real applications. Consider a meta or object creations. object that implements a bounded buffer synchronization A base object also can invoke a method of the meta scheme. It does not make sense to attach it to a base object object directly. This is called explicit meta interaction and is that does not have a bounded buffer semantics (i.e., two used to control the meta level from the base level. operations put and get to access the buffer). Not every object must have a meta object attached to it. void attachObject (MetaObject meta, Object base) Meta objects may be attached dynamically to base objects Bind a meta object to a base object. at run time. This is especially important if a distributed com- MetaObject findMeta (Object base) putation is controlled at the meta level and arbitrary method Find the responsible meta object for a base object. arguments need to be made reflective. As long as no meta Object continueExecutionObject (EventMethodCall event) objects are attached to an application, our meta architecture Continue the execution of a base-level method. This calls the does