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?