Understanding And Using Reflection

Understanding and Using Reflection Summary: Reflection is a powerful language feature. Java supports ‘structural-reflection’, which is safe to use. With reflection, it is possible to do two basic types of operations on code: inspection and manipulation. Reflection enables using ‘signature based polymorphism’ as an alternative to ‘interface based polymorphism’ in Java. Reflection also facilitates creation of flexible and adaptable frameworks and patterns, which is not usually possible with direct code. Though there are many clear advantages in using reflection, like any other language feature, reflection can be misused. This article covers a few specific problems and solutions to illustrate uses and misuses of reflection. In programming, reflection is the ability to dynamically create, use or manipulate classes and objects at runtime. For example, you can create an instance of a class, examine the class to find a specific method from that class and execute that method with the arguments you specify, all this dynamically at runtime using reflection. Reflection is not a new concept. Smalltalk – one of the early and important OO programming language – supported reflection in 1970s itself. Reflection is possible only when sophisticated runtime support is available in the language implementations. C++ follows static compilation model where the code is compiled to native code and executed; the runtime support is limited. So reflection is not possible in C++. However, Java and C# have sophisticated runtime mechanisms (JVM for Java and CLR for .NET), so reflection can be supported in these languages. One of the misconceptions about reflection is that it is difficult to learn or use. By learning a few APIs and basic concepts, even beginners can write simple code using reflection. However, like any other language feature, effective use of reflection takes effort and considerable experience. The reflection feature supported by languages like Java and C# is known as ‘structural reflection’ where only inspection and execution of the code is allowed. There is another form of reflection more sophisticated than ‘structural reflection’, known as ‘behavioral reflection’, which allows us to modify or manipulate the code at runtime [1]. For strongly-typed, commercially widely used languages like Java, ‘structural reflection’ suffices. Reflection is a powerful feature and it is very useful for creating dynamic or adaptable design and for writing development tools. Reflection is also often misused by the programmers. In this article, after a short example for showing a how we write reflection code in Java, we’ll see the advantages, disadvantages, uses and misuses of reflection with focus on disadvantages and misuses of reflection. Reflection Example: Class Dissection

We’ll see small sample program to understand how we can use reflection in Java. Java’s java.lang.Class encapsulates the class that is the basic execution unit of the Java language. This class deals with Java class representation as a whole, and the classes in the java.lang.reflect package deal with the parts of this class, such as methods and fields. Let us consider an example that dissects a class using reflection (with the output of the program shown in comments): class Reflect { public static Constructor [] constructors; public static Method [] methods; public static Field [] fields; public static Class thisClass; static {

try {

}

thisClass = Class.forName("Reflect"); // dissect and see this class itself!

} catch(ClassNotFoundException cnfe) { System.out.println("class doesn't exist " + cnfe); System.exit(-1); } constructors = thisClass.getConstructors(); methods = thisClass.getMethods(); fields = thisClass.getFields();

public static void main(String []args) { System.out.println("This class is "+ thisClass); for(int i = 0; i < constructors.length; i++) System.out.println("Ctor "+ i + " " + constructors[i]); for(int i = 0; i < methods.length; i++) System.out.println("Method " + i + " " + methods[i]); for(int i = 0; i < fields.length; i++) System.out.println("Field " + i + " " + fields[i]); } } // output: // This class is class Reflect // Method 0 public static void // Reflect.main(java.lang.String[]) // Method 1 public native int java.lang.Object.hashCode() // Method 2 public final native java.lang.Class

// // // // // // // // // // // // // // // // // // // // //

java.lang.Object.getClass() Method 3 public final void java.lang.Object.wait(long,int) throws java.lang.InterruptedException Method 4 public final void java.lang.Object.wait() throws java.lang.InterruptedException Method 5 public final native void java.lang.Object.wait(long) throws java.lang.InterruptedException Method 6 public boolean java.lang.Object.equals(java.lang.Object) Method 7 public java.lang.String java.lang.Object.toString() Method 8 public final native void java.lang.Object.notify() Method 9 public final native void java.lang.Object.notifyAll() Field 0 public static java.lang.reflect.Constructor[] Reflect.constructors Field 1 public static java.lang.reflect.Method[] Reflect.methods Field 2 public static java.lang.reflect.Field[] Reflect.fields Field 3 public static java.lang.Class Reflect.thisClass

This code is designed to peek into its own .class file and see what constructors, methods and fields are available inside. The whole code can be written within the main method itself, but this slightly contrived example has fields and a constructor for illustration. Since all the classes inherit from Object the methods of that class are also shown in the output. Advantages of Reflection 1) Signature-Based Polymorphism Java and C# programmers are familiar with polymorphism based on interface inheritance. Reflection provides an alternative where we can invoke methods having same signature, from different classes not have a common interface (which is required in interface based polymorphism). For example, we can implement dynamic observer pattern or command pattern (dynamic design patterns) which invoke a method based on same signature from classes not related to each other by interface inheritance. 2) Inspecting and Manipulating Classes Writing direct code is based on depending on specific class details (like interface, method or field names) known at compile-time. If we need to write code that depends on class details known only at runtime, then reflection comes handy.

3) Creating Adaptable and Flexible Solutions Because of its dynamic nature, reflection is useful for creating adaptable and flexible software that is often not possible with direct code. Theoretically, it is well known that reflection can help add more dynamism and flexibility to frameworks and design patterns. For example, it is possible to write code for factory design pattern by loading the classes using reflection instead of writing fixed code depending on specific static types with if else statements inside the factory method. 4) Writing Tools that Require Implementation Details Many of the developer tools need access to internal or implementation details of the code. For example, an intelligent text editor can query a class using reflection and get details about its implementation, which can be very helpful. When user types in an object name and a ‘.’ to access a member, the text editor can pop with a list box with list of accessible members (obtained using reflection) that the programmer can select from. Since reflection programmatic access to the implementation details of the class, it is very useful for writing program development tools. Problems with Reflection Though there are various benefits in using reflection for adaptable and flexible software, reflection has many problems. 1) Exposes implementation details. Use of reflection essentially exposes much of implementation details – such as the methods, fields, accessibility and other metadata – of the class used. Access to low-level detail through reflection is a necessity for implementing low-level programming tools. But, when using reflection for solving higher-level problems (such as providing dynamic implementations of design patterns), accessing, using and depending on implementation details of classes is not required. One of the major objectives of object oriented programming is information hiding, where only the relevant higher level details of the class that the programmer needs to know are exposed to the users, and low-level implementation details are hidden. Reflection exposes such low-level implementation details of the class to the program. 2) Performance The code that is reflective is slow that the direct code that performs the same functionality. Reflection can be order of times (10 to 30 times) slower than the direct code. Reflection performance also depends on the kind of operations are done in the code (is it creating objects, accessing members, making method calls, etc). If the main logic uses reflection or if the hot-spot function uses reflection,

then we can feel the effect of reflection on application performance. If the reflection code is used sparingly in the application or if the methods using reflection code are rarely invoked, then reflection might not affect application performance. 3) Code Complexity The reflective code is more complex and harder to understand the direct code that performs the same functionality. There are three main problems that affect the readability and maintainability of the code using reflection.

1) Obscures Logic The use of reflection APIs obscures the underlying logic. In direct code for achieving the same functionality, the logic will be straight-forward to understand. However, since all the basic operations in reflection should be done using reflection APIs, the logic gets lost in the maze of API calls. For example, creating an object and invoking a method in that is small and trivial in direct code. For achieving the same using reflection, the class has to be loaded, an object has to be created by programmatically figuring out the correct constructor and pass the necessary arguments, get the meta-data of the class and get the Method object from that class, and then invoke that method on the object by passing necessary arguments. All this requires multiple lines of code and a few exception handlers to ensure that the code doesn’t crash in case if something goes wrong in this process.

2) Missing Static Checks The compiler statically checks the program when code is compiled. For example, the compiler ensures that only valid methods are called based on the static type of the object (to ensure type-safety). However, for equivalent reflective code, the compiler only checks of the reflection APIs are statically correct or not. All the checks involved in actually performing the operation using reflection APIs should be done by the programmer to ensure that the program is type-safe and that we are not violating any semantic rules. For example, if we attempt to invoke bar() method on an object of Object type created using reflection, a runtime exception will be thrown that the method is not found in Object class. Similarly, if you try to access a private member from outside the class, an exception indicating access violation will be thrown at runtime. These two problems would have been caught at compile-time itself in direct code. Consider another example where you’re invoking a method of a specific class using reflection. If the signature of the method changes, then all the code that depends

on that method will fail to compile. However, the code that invokes the method using reflection will not fail at compile time, but it will fail only at runtime.

3) More Exception Handlers The static checks done by a compiler in static code have to be done by the programmers using exception handling code. So, programmers have to provide more exception handlers in reflective code than the direct code. Providing more exception handling code increases implementation/testing effort and complicates application logic, so there is more possibility of making mistakes in code. Because of these reasons, it is more difficult to maintain or debug programs using reflection compared to the direct code that does not use reflection. 4) Security Programmers often cite security as a reason for not using reflection in their code. It is true that there are some security concerns in using reflection, particularly in component and internet programming where the code might be from un-trusted sources. However, in most cases, the security concerns are misguided. The reflection code is still executed under the same watchful eyes of the Java security manager, like any other code. So, just using reflection in the code doesn’t affect the safety of the code or make the code unsafe. Having stated that, reflection does provide some limited ways to circumvent many of the checks that are usually statically checked. For example, in Java, private members are accessible only to the class members. If we attempt to access a private member from code outside the class, it will result in an exception. But by setting the suppressAccessChecks method (provided in java.lang.reflect.ReflectPermission class), access checks can be switched off for that class. So, you can access all members from outside the class using reflection, which has potential for un-secure access to internal data of a class or an object. For more details on security and performance problems with reflection, see [2]. Use and Misuse of Reflection Like any other language feature, reflection can be misused. There are two broad categories in which reflection is often misused. In low-level programming (code that operates at .class file levels), reflection should not be used when better alternatives are available. Similarly, when it is possible to provide a solution with high-level language features, that should be preferred over reflective solution. The use of reflection is warranted if there are no other alternative solutions available to solve the problem. For example, in many programming tools, the specific

class names or details of the classes will not be known at compile-time itself. In those cases, it is necessary to use reflection. There are other cases where there are alternatives available, but not attractive. For example, say we are implementing a Java code browser tool which shows relationship between classes and shows members in the classes for quick reference. A requirement for that tool is that it should work at the bytecode level by reading from the Java .class files. There are two main ways to implement the functionality to analyze the code from the .class files. One is to decompile it and read the class and member details and then use that information to analyze the classes. Another way is to use reflection and infer the class details. We don’t need the sophistication or the implementation complexity of a decompiler, for the simple work of showing class member details. So, using reflection is a better alternative for writing the tool. Depending on the situation in which reflection is used, reflection can be a valid use or misuse. Consider the example of signature-based polymorphism using reflection. Consider that we are developing a GUI software. It has subsystems from various sources like third-party, open-source and in-house. Consider that these classes have a common method draw() which draws the specific image on the display window. Since these subsystems are from different sources, they do not inherit from a common interface class. So, how can you write code to invoke draw method for different classes? One possible solution is to write code to make use of the dynamic type of the object. Check for specific class types in nested if-else statements and provide casts to downcast the object to specific types. Then we can apply the draw method on the specific types. You can easily spot the problem with this approach: switching based on specific dynamic types is a strict no-no in object oriented programming as the code becomes rigid and depends on specific types. Reflection comes handy in this situation: we can inspect the classes at runtime to see if it has draw() method in it. If so, we can invoke the method with the given object to draw the image on the display window. In practice this solution works because the only requirement is that the method with specific signature should be available in the class and it can be resolved and invoked using reflection. Since the code is from different sources, compared to other solutions, this solution using reflection is attractive. This example illustrates the proper use of reflection. Now suppose that we have the same problem to solve but all the sub-systems are developed in-house. Now, we have the option to modify the classes that have draw method to implement from a common interface, say, Drawable. Now we can write code to cast the objects back to Drawable type and call draw method from that. This solution works fine and solves the problem. Instead of this solution, if we use reflection, then it is incorrect. Since there are many problems associated with

using reflection, it is better to avoid reflection in this case and use interface-based polymorphism instead which is a direct solution. Joshua Block, in his book [3], presents the discussion on using interfaces vs. reflection concisely as ‘Prefer interfaces to reflection’. Reflection can be very useful when it comes to implementing tools or technologies that involve the implementation details. For example, tools such as code debuggers, dis-assemblers, class browsers, profilers, code obfuscators and technologies such as JavaBeans, JDBC drivers etc make use of reflection facility to completely access the internal details of the classes to provide dynamically changeable behavior. It is acceptable to use reflection in such tools and technologies; but reflection is not for performing usual tasks that can be done with higher level programming features in application code. Reflection is also a convenient feature that it becomes tempting for a programmer to use. As noted in the disadvantages of reflection section in this article, reflection can negatively impact readability and maintainability of the program. So, overuse of reflection is discouraged, and it is better to limit the use of reflection only when it is required and no other better alternatives are available. Bill Wegner, in his book[4], puts this guideline concisely as, ‘Don't overuse reflection’. Egbert Althammer, based on his research on reflection[1], gives one of his guidelines as: ‘Use reflection only if there are no adequate alternatives’. References: [1] Egbert Althammer, "Reflection Patterns in the Context of Object and Component Technology", PhD thesis, Universität Konstanz, 2001. URL: http://www.ub.uni-konstanz.de/kops/volltexte/2002/803/ [2] Dennis Sosnoski, ‘Java programming dynamics, Part 2: Introducing reflection’, developerWorks, 2003. URL: http://www.ibm.com/developerworks/library/jdyn0603/ [3] Joshua Bloch, Effective Java Programming Language Guide, Addison-Wesley Professional, 2001. [4] Bill Wagner, "C#:50 Specific Ways to Improve Your C#", Addison-Wesley Professional, 2004. All rights reserved. Copyright Jan 2004