CSC/ECE 517 Fall 2011/ch4 4f sl

CSC/ECE 517 Fall 2010/ch4 4f sl

---

Introduction

One of the many advantages of dynamic languages such as Ruby is the ability to introspect—to examine aspects of the program from within the program itself. Java, for one, calls this feature reflection. Sometimes you need to create an instance of class depending upon the parameter passed to a function. This parameter could be the name of the class to be created.

One way to do this is to write conditional loops and create the object. But if there are too many classes then this would become messy. Here comes reflection to rescue.

The word “reflection” conjures up an image of looking at oneself in the mirror—perhaps investigating the relentless spread of that bald spot on the top of one's head. That's a pretty apt analogy: we use reflection to examine parts of our programs that aren't normally visible from where we stand.

In this deeply introspective mood, while we are contemplating our navels and burning incense (being careful not to swap the two tasks), what can we learn about our program? We might discover:

• what objects it contains,

• the current class hierarchy,

• the contents and behaviors of objects, and

• Information on methods.

Reflection in Java

Use of Reflection

Reflection<ref>http://download.oracle.com/javase/tutorial/reflect/</ref> is commonly used by programs which require the ability to examine or modify the runtime behavior of applications running in the Java virtual machine. This is a relatively advanced feature and should be used only by developers who have a strong grasp of the fundamentals of the language. With that caveat in mind, reflection is a powerful technique<ref>http://java.sun.com/developer/technicalArticles/ALT/Reflection/</ref> and can enable applications to perform operations which would otherwise be impossible.

Extensibility Features

An application may make use of external, user-defined classes by creating instances of extensibility objects using their fully-qualified names.

Class Browsers and Visual Development Environments

A class browser needs to be able to enumerate the members of classes. Visual development environments can benefit from making use of type information available in reflection to aid the developer in writing correct code.

Debuggers and Test Tools

Debuggers need to be able to examine private members on classes. Test harnesses can make use of reflection to systematically call a discoverable set APIs defined on a class, to insure a high level of code coverage in a test suite.

A Simple Example

To see how reflection works, consider this simple example:

   import java.lang.reflect.*;
   public class DumpMethods {
      public static void main(String args[])
      {
         try {
            Class c = Class.forName(args[0]);
            Method m[] = c.getDeclaredMethods();
            for (int i = 0; i < m.length; i++)
            System.out.println(m[i].toString());
         }
         catch (Throwable e) {
            System.err.println(e);
         }
      }
   }

For an invocation of:

  java DumpMethods java.util.Stack

the output is:

  public java.lang.Object java.util.Stack.push(
    java.lang.Object)
   public synchronized 
     java.lang.Object java.util.Stack.pop()
   public synchronized
      java.lang.Object java.util.Stack.peek()
   public boolean java.util.Stack.empty()
   public synchronized 
     int java.util.Stack.search(java.lang.Object) 

Drawbacks of Reflection

Reflection is powerful, but should not be used indiscriminately. If it is possible to perform an operation without using reflection, then it is preferable to avoid using it. The following concerns should be kept in mind when accessing code via reflection.

Performance Overhead

Because reflection involves types that are dynamically resolved, certain Java virtual machine optimizations can not be performed. Consequently, reflective operations have slower performance than their non-reflective counterparts, and should be avoided in sections of code which are called frequently in performance-sensitive applications.

Security Restrictions

Reflection requires a runtime permission which may not be present when running under a security manager. This is in an important consideration for code which has to run in a restricted security context, such as in an Applet.

Exposure of Internals

Since reflection allows code to perform operations that would be illegal in non-reflective code, such as accessing private fields and methods, the use of reflection can result in unexpected side-effects, which may render code dysfunctional and may destroy portability. Reflective code breaks abstractions and therefore may change behavior with upgrades of the platform.

Reflection in C++

Use of Reflection

There exist a lot of applications where reflection comes in as a useful technique. So, quite a number of people think that some mechanisms supporting reflection should be added to the next version of C++. Here we present several different aspects of reflection to reflection in C++<ref>http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1751.html#APPROACHES</ref>.

Compile-Time Reflection

Compile-time reflection generally provides mechanisms at the source code level. These mechanisms provide information that can be directly derived from the source code, i.e. information about types and their definitions, variables and executable code like expressions or control structures.

This information can then be used to inject or transform code, to instantiate templates or to generate external data: from simple metrics information to full-fledged representations of the source code entities. This external data together with some injected code can then be used to provide such information at runtime.

An interesting question in C++ is: When is compile-time? A rough distinction of different phases during compilation could be made by separating preprocessing, template instantiation and code generation. (This is not really an accurate description of the C++ compilation model, but sufficient for this discussion.) Is information available on preprocessor macros or physical locations, i.e. source file names and line numbers? More interestingly, is information available about template instantiations and which function of an overload set is called in an expression, or what automatic conversions are applied? A related question is: Is reflection recursive, i.e. is e.g. injected code itself a possible object for reflection?

Most existing approaches for C++ (see below) are realized as pre-compilers that pre-run an external preprocessor, so while typically physical location information is preserved, information about preprocessor macros is not possible and not visible. With this approach, information about template instantiations or overload resolution is not available. But a native reflection mechanism could provide such information, though some of it only at link time (due to export).

Runtime Reflection

Runtime reflection provides mechanisms during program execution. Information available generally includes what objects currently exist of a specific class or which variables have which values. But it also comprises typical debugging information like stack frames or even contents of processor registers.

The manipulation mechanisms include changing values, calling functions or creation of new instances of a type, but also modification of existing functions or classes or addition of new ones. Related to debugging, runtime reflection also provides notification mechanisms for events like calling or leaving a function or creation or deletion of an object.

In many existing approaches, (limited) runtime reflection is provided by creating a meta-data repository and injecting respective code using compile-time reflection.

As already noted above, compile-time and runtime are neither exactly specified here nor do they desribe all possible points when reflection is possible. At least two more phases can be usefully distinguished, namely link time and load time.

Introspection

Reflection can either be a purely informational facility or can provide manipulation facilities. Introspection is generally the informational part of reflection, the mechanism to examine all kind of structure of a program. At compile-time, introspection provides information such as what base classes or what members a class has, but also what statements are in a function definition. At runtime, introspection allows to ask an object about its type, to query the values of an object's data member or to examine the call stack at a specific point in execution. Also at runtime, introspection provides notification of specific events, such as the invocation or exiting of a function, the creation of an object or the throwing of an exception.

Self-Modification

Self-modification generally provides mechanisms to manipulate the reflected entity. At compile-time it allows the deletion, transformation or injection of source code, e.g. addition of members to a class or replacing the target of a function call. At runtime, self-modification allows to invoke functions, to change the values of objects or to create new objects. More importantly, self-modification allows the introduction of new classes and functions at runtime and to make them an inherent part of the running executable.

Drawbacks of Reflection

In both models of using reflection (explicitly described by programmer and extracted from debugging information) there are some limitations<ref>http://www.garret.ru/cppreflection/docs/reflect.html</ref>. Below we enumerate them grouping in three part - common for proposed reflection API and specific for each approach.

Common limitation

• It is possible to create instance of the object only using default constructor.

• API doesn't support enums, unions and bit fields.

• API provides type only information only about classes and structures used in the application - no information about global or static functions and variables is available.

Limitation of extracting information from descriptors written by programmer

• Only restricted set of field types is supported (scalars, classes, structures, array and pointers of those types, pointer to pointers to those types).

• Methods can not have more than 5 parameters

• It is not possible to describe static methods and fields.

• Each class should have public default constructor or have no constructors at all.

Limitations of extracting types from debug information

• This approach works only under Unix and most probably only with GCC (because format of mangling symbols is specific to each compiler)

• It is possible to invoke method only at platforms where parameters are passed through the stack (for example Intel). Unfortunately there is no portable way of invoking arbitrary method in C++.

• There is no way to distinguish classes defined in application from system classes which are also extracted from debug information.

• Virtual methods can be invoked only statically (i.e. if you have class A with virtual method foo and class B derived from class A which overrides foo method, get descriptor of A, find method foo in it and invoke this method, then A::foo will be called)

• No field qualifiers (such as const, volatile,...) are currently extracted.

References

<references/>