General

In general, reflection is supposed to support applications such as: services like JavaBeans (discussed below), object inspectors, development tools including debuggers, interpreters, inspectors, class browsers and run-time services such as object serialization. (Taken from the spec.) The specification divides all these tools into two categories: either they are lightweight in that they need to access only public members of an object or they are more sophisticated in that they need access to all members declared by a given class.

A list of real, concrete applications using an appreciable amount of reflection:

• JavaBeans
• Java Object Serialization
• Java database API's
• OpenJIT: Reflexive compiler

In many cases, applications do not need reflection. However, there are some applications which either would require some really roundabout code to accomplish what reflection does easier or just simply need reflection to do what they are trying to do. In addition, it may be that there are a whole lot of applications which use little pieces of the Reflection API for convenience sake (see the UniversalActionListener example).

[Ferber] gives some applications of reflective systems:

implementation description:

allocation of entities, GC, incremental extension and re-implementation of the whole system.

monitoring entities:

inspection, analysis and dynamic modification of code.

interfacing and debugging:

and other programming tools.

self-reorganization:

learning abilities of the system's behavior for increase in consistency and efficiency.