Reasons to use reflectionAs some of you may know, many frameworks and libraries use reflection to do their thing. Reflection can be a solution for many sorts of issues, like: * Configuration. Many frameworks use text-based configuration, like XML. Classes are often configured in text files and need to be instantiated at some point. Also, method names (like event handlers or callbacks) might be configured in text files.
* Frameworks in general. Whether you configure your classes in an external text file, annotations or some kind of Java config, the framework can never know the classes it invokes. This framework therefore almost always needs to invoke Class.newInstance() or something similar (Constructor.newInstance() is actually better) to invoke the application classes. And, if you don’t want to put any restrictions on the application code, like requiring application classes to implement a predefined interface, you definitely need to use reflection to invoke methods and access fields.
* Backwards compatibility. For example, the BeanValidator in MyFaces needs to behave in two different ways, depending on the available libraries. It uses the method ValueExpression.getValueReference(), but only if it is available (available since Unified EL 2.2). Otherwise, it uses a home-brewn mechanism. Reflection is needed, both for compile and at runtime. Otherwise, the code will throw a NoSuchMethodError when ValueExpression.getValueReference() is not available. Reflection is the way to determine method-existence on classes.
* Tooling, or other kinds of code that need to inspect classes at runtime.
* Simple class modifications, like making private methods accessible. OR-Mappers like Hibernate do this for field access, since fields are usually private.
* Non-Java templating engines, like FreeMarker or Facelets. Since templates are not Java bytecode, they rely on reflection to access Java stuff.Reflection in JSFAs you may know, JSF also uses reflection a lot. Managed Beans, unlike i.e. Struts Actions, don’t have a specific interface, but (mostly) follow the JavaBean convention. This requires the framework to use reflection a lot, for example while resolving EL expressions to method calls. Read more: blog.smart-java.nl
* Frameworks in general. Whether you configure your classes in an external text file, annotations or some kind of Java config, the framework can never know the classes it invokes. This framework therefore almost always needs to invoke Class.newInstance() or something similar (Constructor.newInstance() is actually better) to invoke the application classes. And, if you don’t want to put any restrictions on the application code, like requiring application classes to implement a predefined interface, you definitely need to use reflection to invoke methods and access fields.
* Backwards compatibility. For example, the BeanValidator in MyFaces needs to behave in two different ways, depending on the available libraries. It uses the method ValueExpression.getValueReference(), but only if it is available (available since Unified EL 2.2). Otherwise, it uses a home-brewn mechanism. Reflection is needed, both for compile and at runtime. Otherwise, the code will throw a NoSuchMethodError when ValueExpression.getValueReference() is not available. Reflection is the way to determine method-existence on classes.
* Tooling, or other kinds of code that need to inspect classes at runtime.
* Simple class modifications, like making private methods accessible. OR-Mappers like Hibernate do this for field access, since fields are usually private.
* Non-Java templating engines, like FreeMarker or Facelets. Since templates are not Java bytecode, they rely on reflection to access Java stuff.Reflection in JSFAs you may know, JSF also uses reflection a lot. Managed Beans, unlike i.e. Struts Actions, don’t have a specific interface, but (mostly) follow the JavaBean convention. This requires the framework to use reflection a lot, for example while resolving EL expressions to method calls. Read more: blog.smart-java.nl