Why should I use reflection?

Question

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?

Answer 1

• 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 you would 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 th 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 librory 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.

Answer 2

I'd group uses of reflection into three groups:

1. Instantiating arbitrary classes. For example, in a dependency injection framework, you probably declare that interface ThingDoer is implemented by the class NetworkThingDoer. The framework would then find the constructor of NetworkThingDoer and instantiate it.
2. Marshalling and unmarshalling to some other format. For example, mapping an object with getters and settings that follow the bean convention to JSON and back again. The code doesn't actually know the names of the fields or the methods, it just examines the class.
3. Wrapping a class in a layer of redirection (perhaps that List isn't actually loaded, but just a pointer to something that knows how to fetch it from the database) or faking a class entirely (jMock will create a synthetic class that implements an interface for testing purposes).

Answer 3

Reflection can automatically keep parts of your program in sync, where previously, you would have had to manually update your program to use the new interfaces.

Answer 4

Reflection allows a program to work with code that may not be present and do so in a reliable way.

"Normal code" have snippets like URLConnection c = null which by its sheer presence cause the class loader to load the URLConnection class as part of loading this class, throwing a ClassNotFound exception and exiting.

Reflection allow you to load classes based on their names in string form and test them for various properties (useful for multiple versions outside your control) before launching actual classes that depend on them. A typical example is the OS X specific code used to make Java programs look native under OS X, which are not present on other platforms.

Answer 5

I was like you once, I didn't know much about reflection - still don't - but I did use it once.

I had a class with two inner classes, and each class had lots of methods.

I needed to invoke all of the methods in the inner class, and invoking them manually would've been too much work.

Using reflection, I could invoke all these methods in just 2-3 lines of code, instead of the number of the methods themselves.