Reflections on Remote Reflection

Michael Richmond James Noble

Macquarie University Victoria University of Wellington
[email protected] [email protected]

Abstract programs (meta-level programs) manipulate objects and

values from base-level programs [8, 10, 14]. For example, a
The Java programming language provides both reflec- base-level program to process ticket sales would have ob-
tion and remote method invocation: reflection allows a pro- jects that represented tickets, events for which tickets can be
gram to inspect itself and its runtime environment, remote issued, and patrons who purchase tickets. A meta-level pro-
method invocation allows methods to be invoked transpar- gram would have objects that represented the classes, meth-
ently across a network. Unfortunately, the standard Java ods, fields, and interfaces of the base-level program.
implementations of reflection and remote method invoca- Reflection is often used to support programming tools
tion are incompatible: programmers cannot reflect on a re- such as debuggers and performance monitors. Such a tool,
mote application. using reflection, can gather all the information it needs
We describe how Java systems can be extended to sup- about the classes, class attributes, and objects making up the
port Remote Reflection transparently by extending the program being debugged or monitored. Reflection is also
standard Java API. Remote reflection can support remote used in component-based systems, such as JavaBeans [16]
debuggers, performance monitors, programming environ- or Enterprise JavaBeans [15], so that component containers
ments, application component servers such as Enterprise can adapt themselves to the details of the components they
JavaBeans, and any other Java system that can be distrib- will host.
uted across a network. In theory, reflection and remote method invocation
should be orthogonal — a program should be able to use re-
flection and RMI separately or together without any nega-
1. Introduction
tive interaction between the two facilities. Unfortunately, in
Java, remote method invocation and reflection cannot be
Programming and networking have been converging used together. The meta-level of a Java program can only
steadily since the explosion of the Internet in the middle of reflect on local objects, that is, objects within the same Java
the 1990’s. The Java programming language [5] is the most virtual machine. The failure to support remote reflection has
visible expression of this convergence. Java is designed so several consequences in practice:
that programs can be transported across networks and exe- • Debuggers cannot directly debug programs run-
cuted in a Virtual Machine, unlike many other languages, ning in remote JVMs,
regardless of the actual architecture and operating system of • Program visualisation systems cannot visualise re-
the machines on which it runs. mote programs,
Java specifically supports distributed programming • Component servers (such as Enterprise JavaBeans)
through the Remote Method Invocation (RMI) facility [18]. cannot be managed or debugged remotely.
This allows a program on one machine to use objects and This paper addresses this problem by describing how
programs on remote machines. For example, in a system Java can be extended to support remote reflection. The pa-
used to sell tickets to arts performances and sporting events per is organised as follows: the next section introduces the
a Java Applet running in a web browser could take users’ or- Java mechanisms for reflection and remote method invoca-
ders, then use RMI to send ticket details to a central trans- tion, providing a brief overview of the application program-
action server across the Internet. mer interface of each. Section 3 then describes the problems
As modern programming language, Java also includes with Remote Reflection in Java and presents our design for
support for Reflection [2, 4, 10]. Normal programs (or base- a solution. Section 4 then discusses issues and recommends
level programs) manipulate objects and values that refer to Java API changes to support transparent Remote Reflection.
an external domain in the real world. In contrast, reflective
 Account anAccount = new Account(...);

Class acClass = java.lang.Class.forName(“Account”);

Method deposit = acClass.getMethod(“deposit”,[Class.forName(“int”)]);

deposit.invoke(anAccount, [250]);

Field balField = acClass.getDeclaredField(“balance”);

Figure 1. Java Reflection code fragment.

Section 5 places this work in context of related work, and programmer can use reflection to destroy the integrity of the
Section 6 concludes the paper. base-level program. To avoid these problems, the Reflec-
tion API supports a property, ReflectPermission, in the
JVM environment which disables reflection within that vir-
2. Background
tual machine. This is enforced by the java.lang.re-
flect.AccessibleObject super meta-class in concert
2.1. Java Reflection with any existing security manager.

The Java Reflection application programmer interface 2.2. Remote Method Invocation
(API) allows a running program to retrieve information
about itself and the runtime system (virtual machine) in The Java Remote Method Invocation API is the basis for
which it executes [17]. Using reflection, a program may ob- distribution support in Java. RMI provides location trans-
tain information about its structure and the runtime environ- parent object references, and automatic argument and return
ment. With this information the program can instantiate value marshalling to provide method invocation seamlessly
arbitrary classes, invoke methods, or alter data fields — by- across network and JVM boundaries.
passing any scoping rules or protection boundaries. This When developing distributed applications, operations
makes reflection a powerful but potentially dangerous lan- over the network should appear to behave identically to op-
guage mechanism. The ability to circumvent call stack erations on local objects. In practice this is not completely
scoping and protection boundaries does, however, allow possible, as operations over the network have more failure
certain types of applications to be implemented orthogonal- cases than local operations. These differences are unavoid-
ly to the remainder of the program logic. This is particularly able due to the nature of network communications. The goal
useful when developing applications like debuggers, moni- of network transparency however, is to minimise these dif-
tors, and persistence mechanisms. ferences as much as possible.
Reflection is supported in Java as part of the standard RMI provides network transparent method invocation
Java API. This API provides classes that represent array, for objects that are declared as implementers of the
class, method, field, constructor, and object instances in an java.rmi.Remote interface. This interface defines no
executing Java Virtual Machine (JVM). Because these method signatures, rather, it is used to mark the object as be-
classes are about the program itself they are known as meta- ing remotable. It also provides type equivalence between
classes, and their instances known as meta-objects [8]. the implementation of the remote object class, and the stub
A fragment of code, that uses Java reflection, is shown in classes generated to act as local proxies for the remote ob-
Figure 1. In this example a new Account object is first cre- ject.
ated and a reference to the Class object corresponding to Objects are type equivalent if it is type-safe to use an ob-
the Account class is obtained. This Class object is then ject of one type in place of an object of another type. In the
used to locate the Method object for a deposit() method, case of RMI both the implementation of the remote object
which takes an integer as its argument, in the Account and the generated stub object implement the same interface:
class. i.e., the interface defined for the remote object. In the Java
A deposit is then performed on the Account object by type system, this means the client of a remote object can de-
invoking the deposit() method using an instance of the fine a variable to hold a reference to an object whose type is
Method meta-class. Finally, the code obtains the reflection the remote interface of the remote object. As long as the ob-
class representing the private field balance in the Ac- ject is accessed through this variable the client will only see
count class. an object of the remote interface type.
Since reflection is inherently dangerous it is obvious to Remote operations via RMI are constrained to those that
question the inclusion of it in a language: an unscrupulous may be performed on a standard Java interface, that is, the
 Client JVM Server JVM

Transaction Account

Account Account
Stub Skel

logical reference actual reference (and call path)

Figure 2. Overview of Java Remote Method Invocation model.

RMI API does not support client access to fields of remote Under RMI all invocation arguments are passed by copy
objects, nor does it support access to static fields or methods to the server JVM. After the method call has completed only
in the remote class. the explicitly declared return value is returned to the client.
A functional overview of the RMI call path is shown in As a result, the server developer must be careful to ensure
Figure 2. In this example, the Account object is providing that they do not rely on side effects in the server object.
a service which is accessed by the Transaction object. When passing structural objects such as arrays, vectors
Each of these objects are located in different JVMs, poten- and trees it is important to remember that only the root ob-
tially on separate hosts. In the case of both objects residing ject is passed by RMI. The developer must ensure that the
in a single JVM the RMI sub-system is able to invoke the elements contained within these structures are remotable
method directly, thus bypassing the marshal/unmarshal objects, otherwise, fatal exceptions will be raised on the cli-
process. ent during unmarshalling.
RMI allows the developer to act as though the client Figures 3 and 4 show an example of the code required to
holds a reference directly to the server object. This logical make a Java object accessible using RMI. The programmer
reference can be treated like any other local reference. In must create an interface for the object to act as the remote
our example, the Transaction object logically holds a ref- interface for the object. This interface must extend the
erence directly to the Account object. java.rmi.Remote interface and declare all methods to
In reality, the reference held by the client refers to a stub throw java.rmi.RemoteException. If an error occurs
object in the local JVM. The implementation of this stub is during the remote method invocation an exception will be
generated at compile time by rmic — the Java RMI stub returned to the client that is a sub-class of java.rmi.Re-
compiler. This stub object performs the marshalling of in- moteException.
vocation arguments, that is, it collects the Java objects and The implementation of the remote object must be de-
encodes them so that they can be transmitted across the net- clared to as implementing the previously defined remote in-
work. The stub then communicates with the server, unmar- terface. Each public method in the remote interface must be
shalling any return value. Importantly, the stub also implemented in this class and declared as throwing
implements the remote interface of the remote object, there- java.rmi.RemoteException.
by ensuring the stub’s type is equivalent to the remote ob-
ject’s type. (In this case, the Account Stub will effectively
3. Remote Reflection
have the same type as the Account object since the stub im-
plements the Account class’s remote interface).
The stub object communicates with a matching skeleton The ability for a program to examine itself via reflection
object in the server’s JVM. This skeleton is generated by can be extremely useful when developing certain types of
rmic at the same time as the stub class. Starting with ver- applications. When using a monitor or debugger to observe
sion 1.2 of the Java SDK, these skeleton classes are gener- a program it is desirable to minimise the impact that the ob-
ated at run-time by the server JVM if they cannot be found server has on its subject. The introduction of any additional
by the server. The skeleton object is responsible for unmar- process into a system will potentially alter the behaviour of
shalling any invocation arguments, performing the local the program being observed. With multi-threaded and syn-
method invocation on the server object, and marshalling chronous programs this is particularly evident, with addi-
any return value. tional processes altering the scheduling behaviour of the
system.
 import java.rmi.*;
import java.net.URL;

public interface Account extends java.rmi.Remote {

public void deposit(int amount) throws RemoteException;

public int getBalance() throws RemoteException;

}
Figure 3. Java RMI interface code fragment for Account.class.

import java.rmi.*;
import java.rmi.server.RMIClassloader;

public class AccountImpl implements Account {

private int balance;

...
public void deposit(int amount) throws RemoteException {
balance += amount;
}
...
}

Figure 4. Java RMI object implementation code fragment for AccountImpl.class.

For distributed systems, it is preferable use a single de- reflection to develop remote and distributed monitors, de-
bugger or monitor to observe the entire system from one buggers, and visualisation tools.
place rather than being tied to the location of each compo- There are a two main reasons for this restriction. The first
nent in the system. To achieve this the debugger must know is that the reflection API relies on the static methods
how to observe over a network, in addition to observing lo- Class.forName() to provide instances of reflection ob-
cal components. In RMI we have a mechanism which al- jects. If we are to provide remote reflection, then some way
lows remote operations to be performed as if they were local of remotely calling these static methods must be provided.
operations. Rather than re-implement a remote operation The second, and most important reason, is that the core
mechanism, it makes sense to use RMI to access the remote reflection classes are defined as final in the standard Java
components in the system. API, thus preventing the programmer from sub-classing to
When implementing such a debugger, the programmer extend functionality.
must avoid reliance on language features not supported by
the RMI model. Specifically this means that all objects must 3.2. Final Classes
define interfaces, no static methods are used, and object
fields are accessed via get and set methods rather than di- With most Java classes it is a trivial to use sub-classing
rectly. to make them remotable. The Java keyword final, how-
As long as these constraints are observed, the conversion ever, prevents programmers from sub-classing a particular
of a local debugger or monitor into one which can act re- class. There are three possible reasons for this decision.
motely should be trivial. Unfortunately, the Java reflection First, there is the need to prevent programmers from sub-
API restricts reflection to the local JVM. classing the reflection classes to expose their constructor
methods. In a fully reflexive language, it is possible to alter
3.1. The Problem the language semantics by over-riding parts of the reflection
classes, for instance, over-riding Method.invoke() to
The current implementation of the Java Reflection API change the semantics of method invocation. In Java, the re-
(SDK 1.3) restricts reflection to the local JVM state. In spite flection classes are representations of the underlying virtual
of the RMI model making the question of locality orthogo- machine state rather than the actual JVM state. It is there-
nal to the class implementation in most cases. This inability, fore not possible to use reflection in Java to alter the lan-
to use reflection to act upon remote objects, breaks the RMI guage behaviour. Furthermore, it is necessary to ensure that
goal of providing network transparency to developers of only the JVM is capable of creating reflection objects. Oth-
distributed systems, thus, preventing developers from using
 Server JVM
Debugger JVM
Class
Display ClassProxy "Account"
Class

ClassProxy ClassProxy Account

Stub Skel instance

Figure 5. Proxy model of remote reflection.

...

Class MethodProxyImpl implements ClassProxy {

Method method;

public ClassProxy getDeclaringClass() throws RemoteException {

return (ClassProxy) new ClassProxyImpl(method.getDeclaringClass());
}
...
Figure 6. Remote Reflection proxy code fragment.

erwise, the integrity of the Java Reflection mechanism 3.4. Implementation

would be undermined.
The second reason is that reflection classes typically ac- The implementation of these proxy classes is quite sim-
cess the JVM data structures directly through native meth- ple. One proxy class exists for each Java reflection meta-
ods. The result is a tight coupling between meta-objects and class. At run time, each proxy object holds a reference to the
base-objects, binding the reflection implementation to a meta-object that it proxies. The proxy class implements
specific JVM. This constrains meta-objects to exist in the every method in its corresponding meta-class, by calling the
same JVM as the base-objects they reflect upon. appropriate method of the meta-object it represents (as
Finally, there is the view that reflection allows you to in- shown in Figure 6). For the methods where the reflection
spect, reason and act at the meta-level of a program. With class returns an array of reflection objects, the proxy is re-
the presumption that access to this meta-level will only be sponsible for generating a matching array of proxy objects
required from within the program being reflected upon. to be returned to the reflection client.
The reflection API is fairly self contained, with reflec-
3.3. Solution tion objects being used mainly by the reflection API. This
means our proxy classes need not be type equivalent with
To bypass these problems, we have written a set of proxy the classes they represent, rather, they form a parallel proxy
[3] classes which mirror the method signatures of the Java API. In any event, type equivalence is prevented by the dec-
reflection classes. These proxies reside in the same JVM as laration of the reflection classes as final. The drawback is
the standard reflection meta-objects, i.e., in the same JVM that remote reflection references cannot be used within the
as the base-level objects being reflected upon. Unlike the reflected JVM after being passed there via some channel.
standard meta-objects, these proxies are remotable (they It’s important to note that this implementation is solely
implement the java.rmi.Remote interface) and so can be within the Java language, and does not require any modifi-
referenced remotely. (See figure 5.) cations to the Java Virtual Machine. This has several advan-
Our proxy classes do not fully solve the problem of pro- tages. Most importantly, the remote reflection mechanism
viding Remote Reflection in Java. They do, however, pro- will operate on any JVM that implements the standard RMI
vide an effective practical solution, while helping us and reflection interfaces. The remote reflection mechanism
identify necessary changes to the Java API. These changes can be loaded into any running JVM, without requiring the
are presented in the section 4.1 of this paper. JVM to be restarted, reloaded, or re-compiled. Java lan-
guage-level programming is also much simpler than modi- This changes the last limitation into one of class equiva-
fying a JVM. lence. Class equivalence is considered in section 4.3 of this
The drawback is that our implementation is not com- paper.
pletely transparent. Our proxy objects can be used only in
calls to other proxy objects. That is, we cannot use these 4.1. Changes to the Java API
proxy classes in calls to the standard Java reflection API.
Additionally, some well known home for the Class.for- The first problem with the Reflection API is that none of
Name() methods is required in the remote JVM to act as an the classes it defines are remotable. One solution is to not
object factory [3] for the ClassProxy instances. This is a define the API classes as final. Thus allowing program-
result of RMI not supporting static methods in remote class- mers to use the RMI metaphor of sub-classing to implement
es. the empty java.rmi.Remote interface to make the class
In our project we were sure that proxy references and re- remotable. Unfortunately, this would allow programmers to
flection API references would not be combined in a method sub-class to expose the constructors of the reflection API.
invocation. In general use, however, the programmer must
ensure that any proxy references transferred to the remote 4.2. Reflection API Changes
JVM are not used in calls to the reflection API. This will be
caught by the type checker during compilation, but ideally A better solution is to change the reflection API so the
a remote reference to a reflection object could be used in constructors are declared as final, allowing API exten-
any call to the reflection API. The changes to the Java Re- sions without exposing the object constructors. The Java
flection API we suggest in section 4.1 remove this distinc- language however, does not allow constructors to be de-
tion between remote and local reflection references. clared final [5].
Additionally, programmers must not expect object Our preferred solution is to make the API classes imple-
equality based on identity between reflection references and ment the java.rmi.Remote interface. Every Java reflec-
reflection proxy references. Rather, the equality of these tion class, with the exception of java.lang.Class,
references should be based on object value. For example, it already inherits from java.lang.reflect.Accessi-
is reasonable to test if the local Class object for bleObject. As Class and AccessibleObject do not
java.lang.String is equal to the remote Class object explicitly inherit from any other class, this would not dis-
for java.lang.String. This will fail, however, when us- rupt the existing class hierarchy. Additionally, Accessi-
ing our proxies to access the remote Class object, since the bleObject will need to implement the empty
programmer is comparing a Class object to a ClassProxy java.io.Serializable interface to comply with RMI
object. API requirements.
These changes will allow remote access to the Java Re-
flection objects, ensuring type equivalence between remote
4. Discussion
and local references. They will also prevent programmers
from implicitly reflecting on the RMI stub objects, effec-
The use of proxies to make Java reflection accessible tively by-passing them during RMI method invocation. If it
from a remote machine has been successful. They have al- is necessary to reflect on the stub and skeleton objects the
lowed us to use an existing object visualisation tool to in- programmer can still use instanceOf() and appropriate
spect, and act on, a remote Enterprise JavaBeans server. For type casting to explicitly reflect upon these classes.
general use, however, some limitations remain. Namely: A second issue with these API changes is that RMI does
• the reflection proxies are not type equivalent to the not support static methods on remote objects. In the Reflec-
reflection classes they represent, so cannot be in- tion API, every reflection class is effectively instantiated
terchanged in method calls, via a Class object. These Class objects are instantiated by
• some object is required, on the remote host, to act calling either java.lang.object.getClass() or the
as an object factory [3] for ClassProxy instances, static java.lang.Class.forName() methods.
• extra overhead is introduced by the proxy objects, To support remote instantiation of Class objects it is
• object equivalence between reflection proxies and therefore necessary to modify the Class class and the JVM
reflection classes is not provided. to allow the programmer to specify whether a call to
All but the last of these limitations can be solved by al- java.lang.Class.forName() is fulfilled in the local
tering the Java Reflection API to support RMI. In effect col- JVM or in a specified remote JVM.
lapsing the proxies into the reflection objects themselves.
4.3. Class Equivalence Problem Furthermore, many languages combine reflection and
distribution, often, as in CodA or ABCL/R relying on re-
With these changes to the Java Reflection API, it will be flection to implement distribution [11, 12]. In particular,
possible to use reflection to inspect and act upon a remote distributed versions of Smalltalk, one of the oldest object-
JVM, achieving our original goal of allowing programmers oriented languages, have to solve many of the problems we
to use Java Reflection remotely. encountered to support remote reflection [2, 13]. Due to the
As previously noted, however, the problem of class orthogonal nature of Smalltalk’s design, this can be done
equivalence remains. These API changes will make it pos- much more easily that we have in Java. Indeed, our work
sible for a programmer to instantiate a Class meta-object can be understood as applying techniques developed for
for the class java.lang.String in a remote JVM, and a Smalltalk to Java, and understanding where they break
second Class meta-object for java.lang.String in the down, as in the case of final and static methods, which are
local JVM. This is a problem: we will have two potentially part of Java but are not part of Smalltalk.
unequal instances of the Class object in the distributed sys-
tem. We refer to this as the class equivalence problem.
6. Conclusion
As discussed by Liang and Bracha it is possible for two
instances of a user-defined class to exist within a single
JVM. This may occur when a class is loaded by two sepa- Java Reflection and Remote Method Invocation should
rate class loaders. In this case the classes are not considered be orthogonal. A program should be able to reflect upon any
to be of the same type in Java since a class type is uniquely object, local or remote. Any object, base-level or meta-lev-
identified by the combination of class name and class load- el, should be able to be made remotable. In standard Java
er [9]. this is not the case: meta-objects from the reflection API
In the local case, the loading of system classes is delegat- cannot be accessed remotely. We have described how Re-
ed to the Java system class loader which ensures only one mote Reflection can be implemented within the standard
meta-object for each class exists in the JVM. This is Java environment, without modifying the underlying virtual
achieved by having class loaders delegate the loading of machine.
Java system classes to the system class loader [9], guaran- We have also recommended changes to the standard Java
teeing that all system meta-objects are unique. Within a sin- API which will allow Java Reflection to be used remotely
gle JVM all references to the java.lang.String meta- while avoiding the limitations encountered when using a
object will be equal on the basis of object identity. Without purely Java solution.
this guarantee the type safety of the system would be violat-
ed [9].
7. Acknowledgements
With remote reflection, however, each JVM has its own
version of each class so there can be multiple instances of
meta-objects, even for standard systems classes. In practice, The authors wish to thank to thank Randy Smith for his
however, only one of these meta-objects is the “real” meta- assistance during the implementation of this work. We are
object for that JVM: because the remote meta-objects can grateful to SunLabs, California for their making this re-
only reflect upon base-objects from their own JVM, they search possible through their student intern program.
cannot affect the integrity of any other systems. Java, JavaBeans, and Enterprise JavaBeans are trade-
marks of Sun Microsystems.
5. Related Work
8. References
Neither reflection nor distribution are novel features of [1] Birrel, A., Nelson, G., Owicki, S., & Wobber, E. Network
programming languages, whether or not they are object-ori- Objects. SOSP Proceedings, 1993.
ented. Lisp, Smalltalk, Self, and Java are just a few of the [2] Foote, B. & Johnson, R. E. “Reflective Facilities in Small-
reflective languages in common use today [2, 4, 5, 19]. talk-80”, OOPSLA’89 Proceedings, ACM Press, October
Some of these reflective languages are very powerful in- 1989.
deed, for example, the CLOS object system is effectively [3] Gamma, E., Helm, R., Johnson, R. & Vlissides, J. “Design
implemented by a set of meta-objects that can be altered or Patterns: Elements of Reusable Object-Oriented Soft-
replaced to change CLOS's behaviour [7, 8]. Emerald, Mod- ware”, Addison-Wesley, 1995.
ula-3, Smalltalk, and Java once again are just a few of the [4] Goldberg, A. & Robson, D. “Smalltalk-80: The Language
languages with in-built in support for distribution, and thus and its Implementation”, Addion-Wesley, 1983.
remote invocation [1, 6, 13, 15, 18].
[5] Gosling, J., Joy, B. & Steele, G. “The Java Language [13] McCullough, P. L. “Transparent Forwarding: First Steps”,
Specification”, Addison-Wesley, 1996. OOPSLA ‘87 Proceedings, ACM Press, October 1987.
[6] Jul, E., Levy, H., Hutchinson, N., & Black, A. Fine- [14] Smith, B. C. “Reflection and Semantics in Lisp”, Proceed-
grained mobility in the Emerald system. ACM TOCS, V6 ings of the Principles of Programming Languages Confer-
N1, 1988. ence, ACM Press, 1984.
[7] Keene S. E. “Object-Oriented Programming in Common [15] Sun Microsystems, “Enterprise JavaBeans Specification
Lisp: A Programmer’s Introduction to CLOS”, Addison- version 1.1”, Sun Microsystems, Palo Alto California, De-
Wesley 1989. cember 1999.
[8] Kiczales, G., des Rivieres, J. & Bobrow, D. G. “The Art of [16] Sun Microsystems, “JavaBeans Specification version
the MetaObject Protocol”, MIT Press, 1991. 1.01”, Sun Microsystems, Palo Alto California, December
[9] Liang, S. & Bracha, G. “Dynamic Class Loading in the 1998.
Java Virtual Machine”, OOPSLA ‘98 Proceedings, ACM [17] Sun Microsystems, “Java Core Reflection Specification
Press, October 1998. version 1.3”, Sun Microsystems, Palo Alto California, De-
[10] Maes, P. “Concepts and Experiments in Computational cember 1999.
Reflection”, OOPSLA ‘87 Proceedings, ACM Press, Oc- [18] Sun Microsystems, “Java Remote Method Invocation
tober 1987. Specification version 1.3”, Sun Microsystems, Palo Alto
[11] Matsuoka, S., Watanabe, T., Yonezawa, A. Object-orient- California, December 1999.
ed concurrent reflective languages can be implemented ef- [19] Ungar, D. & Smith, R. B. “Self: The Power of Simplicity”,
ficiently. OOPSLA’ 92 Proceedings, 1992. OOPSLA ‘87 Proceedings, ACM Press, October 1987.
[12] McAffer, J. Meta-level programming with CodA. In
ECOOP Proceedings, 1995.