In reply to a comment on my switch post, I would like to discuss reflection which is a rather unusual language feature.

Reflection is a feature in the Java programming language. It allows an executing Java program to examine or “introspect” upon itself, and manipulate internal properties of the program. For example, it’s possible for a Java class to obtain the names of all its members and display them. The ability to examine and manipulate a Java class from within itself may not sound like very much, but in other programming languages this feature simply doesn’t exist. For example, there is no way in a Pascal, C, or C++ program to obtain information about the functions defined within that program.

Besides the article above sun has a tutorial on reflection which starts with the following quote:

First, a note of caution. Don’t use the reflection API when other tools more natural to the Java programming language would suffice. For example, if you are in the habit of using function pointers in another language, you might be tempted to use the Method objects of the reflection API in the same way. Resist the temptation! Your program will be easier to debug and maintain if you don’t use Method objects. Instead, you should define an interface, and then implement it in the classes that perform the needed action.

Another introduction contains this warning:

Reflection gives your code access to internal information for classes loaded into the JVM and allows you to write code that works with classes selected during execution, not in the source code. This makes reflection a great tool for building flexible applications. But watch out — if used inappropriately, reflection can be costly. […]

The article provides several arguments against using reflection:

  • performance: even with the improvements of java 1.4, reflection is still way slower than direct method calls!
  • obscurity: reflection makes code hard to read and understand because it obscures actual program logic
  • complexity: (unnecessary) complexity creates (unnecessary) bugs.
  • security: code access may be limited and programmers may be tempted to off security to ease working with reflection!

As one can see, I need to quote lots of articles to make my point. I have only used reflection in one case up to now: I wanted to make my program “configurable” and allowed to configure via a property which class was going to be used at runtime. It wasn’t a performance problem because the code in question was called once at startup time, it wasn’t obscure because in this special case the reflection was limited to very simple object creation and therefore it was neither very complex. There were no security issues either and still I would say it was unnecessary because I could have solved the problem without reflection even easier.

Same goes for replacing the switch with reflection in my opinion. The difference for the “switch” is, that it may very well be a performance issue because I’ll be creating a lot of these classes at runtime and therefore this code will be executed very often! Still I think it is a good idea to check out the reflection variant as an exercise to practice programming skills, I would just never put this in production code. As with the switch/enum I think it is good to check out several possiblities to know you chose the one best suited to the problem. The reflection variant may be useful for testing as well, because it’s a secondary approach to the same problem.

My question now is where do I need and use reflection? I have read that it’s used extensively with j2ee beans and framework type software and I can imagine that some of the “code generation” features of java IDEs are probably using reflection. Anything else come to mind?







One response to “Reflection”

  1. uli Avatar

    I would differentiate two cases:
    – You know all the classes that a system you use at compile time.
    – You don’t know all the classes that a system may use at compile time.

    In the first case, I think you don’t need any reflection. You can simply use a factory method for configuration purposes, or you can have a switch on a type field of a class, if you really need this feature (the only purpose I know where you normally need a type field is in fact a compiler). It’s much faster and easier to read than reflection.

    If you don’t know all the classes during compile time, than reflection might be a appropriate method to implement a factory for software modules. This is for example the case when you have a program that you can extend with plug ins: You put the binary of the plug in in a special directory, and the application will recognize it. Therefore the application has to find out which functionality is provided by this plug in. That’s the point where you can’t go without some meta information about the classes, and reflection offers this information in a consistent way (windows DLLs contain a table of all methods. You can get the function pointer by querying the name).

    So the short answer is: I would use reflection only for factory capabilities of code that is linked during runtime. For all other cases, I would not use it (for the reasons mentioned above.)