Gilad Bracha and David Ungar Sun Microsystems

Linguistic Reﬂection Via Mirrors

• This work is about how to structure the API for reﬂection in an object oriented language • Most of this is old work: Self, then Strongtalk, then JDI - but • never properly discussed in the literature; it needs to be

There was an old woman who lived in a shoe

Sneaker

getClass()

OldWomanProxy ShoeProxy

getClass()

OldWomanProxy Proxy ShoeProxy

getClass() Sneaker OldWomanProxy ShoeProxy Proxy

Sneaker

getClass()

• Who your class is is ﬁxed and exposed to your clients via getClass() • We can’t replace the implementation of getClass()

• Confusion between base level and meta level • Ask a base level question: What kind of shoe? • Get a meta level answer: Proxy • Hard to tell what answer is required; depends who’s asking

Base level Meta level

Sneaker Shoe getSuperclass() getClass()

Base level Meta level getSuperclass() Sneaker Class Mirror on Sneaker Class Mirror reﬂect on Shoe getClass() getClassMirror()

an ObjectMirror reﬂect

getClass() Sneaker OldWomanProxy ShoeProxy Proxy

Sneaker

getClass()

Base level Meta level getSuperclass() Class Mirror on Sneaker Class Mirror on Shoe

getClassMirror()

an ObjectMirror reﬂect

• Mirrors provide a functional decomposition • Different implementations possible, e.g., local, remote, source based • All can conform to common interface • Subsume core reﬂection, JDI, javadoc, APT

Base level Meta level getSuperclass() Class Mirror on Sneaker Class Mirror on Shoe

getClassMirror()

an ObjectMirror reﬂect

Base level Meta level getSuperclass() Class Mirror on Sneaker Class Mirror on Shoe

getClassMirror()

an ObjectMirror reﬂect

• Easy to deploy without reﬂection • Useful when security or footprint are an issue • Unlike static solutions, you can ...

• add or remove it dynamically

Base level Meta level getSuperclass() Class Mirror on Sneaker Class Mirror on Shoe

getClassMirror()

an ObjectMirror reﬂect

Object ObjectMirror Class ClassMirror Method MethodMirror Stackframe StackframeMirror local variable ?

comment ? program counter ?

Object ObjectMirror Class ClassMirror Method MethodMirror Stackframe StackframeMirror local variable ?

comment ? program counter ?

• Traditional reﬂective APIs do not reﬂect the internals of a method • Debuggers need this; APIs often provide raw byte code (VML) which clients attempt to decompile • Issues: ability to reconstruct source

Object ObjectMirror Class ClassMirror Method MethodMirror Stackframe StackframeMirror local variable VariableMirror

comment ? program counter ?

• The word program is ambiguous • Must distinguish between • Code: A description written in some programming language • Computation: An executing computational process • Code is intentional, declarative, static • Computation is extensional, stateful, dynamic

Copyright Gilad Bracha 2002-2005 Code vs. Computation (2) • An API like JDI is not well suited to writing a class browser that examines source ﬁles • Notions like active threads, call stacks, object instantiation assume a computation • Conversely, source code contains things like comments that might not be available at run time • Metaprogramming APIs should model the commonalities and distinctions between code and computation

Object ObjectMirror Class ClassMirror Method MethodMirror Stackframe StackframeMirror local variable VariableMirror

comment CommentMirror program counter ?

Copyright Gilad Bracha 2002-2005 Which Language to Reflect? • Reflect at source level or VM level? • Implementation requires reflective access to VM • VM may support high-level language(s) with different semantics • Each HLL must have its own reflective API, or semantic discrepancies will arise • Example: Strongtalk separates mirrors into low and high levels

• VM does not directly support nested classes • Compiler uses synthetic members as part of translation from HLL (Java) to VML (Java byte code) • Core reﬂection exposes all members, synthetic or not, exposing translation strategy

Copyright Gilad Bracha 2002-2005 Unifying Reflection and Metaprogramming • If one models the ontology of the programming language, both structurally and temporally, one may be able to unify reflection and metaprogramming • Use consistent framework for compilers, assemblers, debuggers, browsers and for reflection • Example applications: javac, javap/ jdis/jasm/jcod, verifier, JIT.

• The ideal reflective API: • Corresponds to the language, structurally and temporally • Respects encapsulation and stratification • Supports introspection, self- modification and intercession • Are these goals mutually consistent?

• Self • Strongtalk • JDI • APT • Wirfs-Brock/Smalltalk Firewall • MOP • Class loaders • Templ/Oberon • MetaBeta, Yggdrasil • Lorenz & Vlissides