Using Java Reflection to initialize member variables

Question

I'm hoping someone can point in the direction of some useful information pertaining to the best practices surrounding the use of Reflection in Java.

The current project I'm supporting uses Oracle ADF Faces and we've found that based on the objectives at hand certain pages end up with a vast number of components which need to be initialized in the backing beans. One of the developers on the team devised a solution using reflection in the bean constructor to initialize all of the member components for a particular page.

The concern has been raised that this may violate best practices and though it may save individual developers some time it may impact the performance of the application.

Has anyone utilized reflection in this way? Is it acceptable or should the developers manually write out the code?

Answer 1

Reflection should be avoided when possible, because you should take care of some tasks that are normally of the compiler competence; furthermore, the use of reflection makes refactoring harder, because some tools doesn't work on reflection (think about eclipse's refactor).

Reflection have an impact on performances, but I think this is a minor problem in respect of the mantainability issues.

If you have a solution that doesn't use reflection, use it.

Answer 2

Reflection is ubiquitous in web frameworks. Action-oriented frameworks such as Struts2 use reflection to initialize properties of each action with parameters from the request. JPA implementation like Hibernate use reflection to initialize properties of entities. Dependency-injection systems like Spring, Pico, and Guice use reflection to initialize complex dependency graphs for all sorts of objects.

The success of these projects show the viability of reflection in this application.

Answer 3

I generally opt for explicit initialization using a framework such as Spring. Over use of reflection can lead to code that's hard to maintain or at the very least difficult to read.

Although reflection is faster with modern JVM's you still suffer a performance hit.

Answer 4

It depends on how you use reflection...

Reflection against objects' public API (for example using introspection on beans) can be very useful and save a lot of developer time.

Reflection against objects' private fields (or other encapsulation-breaking use of reflection) can very quickly get you in trouble...

Answer 5

I think your natural bias against reflection is well warranted. I've seen it abused, and it isn't pretty.

That being said, if your reflection routine is robust enough to be agnostic about the types of the member variables and the names of the member variables (that is, you are not just rewriting the member variables in strings) so that refactoring the class is demonstrably safe, then I would consider it.

In terms of performance, it is likely a premature optimization to reject reflection just for that reason, and it is probably better to benchmark and see if it is an issue.