Java Reflection – Why Use Reflection?

javareflection

I am new to Java; through my studies, I read that reflection is used to invoke classes and methods, and to know which methods are implemented or not.

When should I use reflection, and what is the difference between using reflection and instantiating objects and calling methods the traditional way?

Best Answer

Reflection is much slower than just calling methods by their name, because it has to inspect the metadata in the bytecode instead of just using precompiled addresses and constants.
Reflection is also more powerful: you can retrieve the definition of a protected or final member, remove the protection and manipulate it as if it had been declared mutable! Obviously this subverts many of the guarantees the language normally makes for your programs and can be very, very dangerous.

And this pretty much explains when to use it. Ordinarily, don't. If you want to call a method, just call it. If you want to mutate a member, just declare it mutable instead of going behind the compile's back.

One useful real-world use of reflection is when writing a framework that has to interoperate with user-defined classes, where the framework author doesn't know what the members (or even the classes) will be. Reflection allows them to deal with any class without knowing it in advance. For instance, I don't think it would be possible to write a complex aspect-oriented library without reflection.

As another example, JUnit used to use a trivial bit of reflection: it enumerates all methods in your class, assumes that all those called testXXX are test methods, and executes only those. But this can now be done better with annotations instead, and in fact JUnit 4 has largely moved to annotations instead.

Related Solutions

Java – Does reflection in Java make its functions “first class”

A first class function is one where the function is available on its own. C, C++, and Ruby allow this approach. Java requires the function to be tied to a class and only provides a metadata representation of it, even if that class is merely a static collection of functions. C# supports first class functions with lambdas (which are based off of lambda calculus) and delegates.

Ruby is one of the languages that truly supports first class functions. The difference is that not only can you define functions on their own, but you can pass them as arguments and invoke methods on them. Check out Ruby's Proc object which is used to represent an arbitrary block of code.

The end result of having first class functions is the fact that it lends to some very powerful and flexible coding constructs. This is distinctly different than hacking around first class functions using the reflection API.

Java doesn't have full support of first class functions. The reflection API can give you some semblance of first class functions if the Method object is referencing a static method. In essence you can invoke a static method like this:

Method reference = mathClass.getMethod("sqrt");

// NOTE: the first parameter is for the object instance,
// but for static methods it is ignored
double answer = (double)reference.invoke(null, 4);

As soon as you are working with an instance method, you lose that first class function ability. You might be able to hack together some reflection based delegate support similar to C#, but the resulting code will be much slower. The "delegate" would take care of keeping the object reference for future invocations.

Java – Is it a bad habit to (over)use reflection

Reflection was created for a specific purpose, to discover the functionality of a class that was unknown at compile time, similar to what the dlopen and dlsym functions do in C. Any use outside of that should be heavily scrutinized.

Did it ever occur to you that the Java designers themselves encountered this problem? That's why practically every class has an equals method. Different classes have different definitions of equality. In some circumstances a derived object could be equal to a base object. In some circumstances, equality could be determined based on private fields without getters. You don't know.

That's why every object who wants custom equality should implement an equals method. Eventually, you'll want to put the objects into a set, or use them as a hash index, then you'll have to implement equals anyway. Other languages do it differently, but Java uses equals. You should stick to the conventions of your language.

Also, "boilerplate" code, if put into the correct class, is pretty hard to screw up. Reflection adds additional complexity, meaning additional chances for bugs. In your method, for example, two objects are considered equal if one returns null for a certain field and the other doesn't. What if one of your getters returns one of your objects, without an appropriate equals? Your if (!object1.equals(object2)) will fail. Also making it bug prone is the fact that reflection is rarely used, so programmers aren't as familiar with its gotchas.

Best Answer

Related Solutions

Java – Does reflection in Java make its functions “first class”

Java – Is it a bad habit to (over)use reflection

Related Topic