/* Last edited @(#)faq.html 1.1 01/05/98 */

Reflection FREQUENTLY ASKED QUESTIONS
Reflection Home Page | Specification | Reflection API Re ference
What kind of applications might want to use the Reflection API? The Reflection API is intended for use by tools such as debuggers, class browsers, object inspectors, and interpreters. When should the Reflection API not be used? You should avoid the temptation to use the reflection mechanism when other tools more natural to the language would suffice. If you are accustomed to using function pointers in another language, for example, you might think that using `Method` objects are a natural replacement, but usually an object-oriented tool, such as an interface that is implemented by objects that perform the needed action, is better. Programs that needlessly use the Reflection API will be more difficult to read, debug, and maintain. If the constructor of a class is overloaded, does the `Constructor.newInstance()` method use the types of the arguments to select an overloading? No. The `Constructor.newInstance()` method is always invoked on a specific overloading of the constructor, previously selected by a call to `Class.getConstructor()` or by other means. The Reflection API does not automatically choose between overloadings. If a class has an overloaded method, does the `Method.invoke()` method use the types of the arguments to select which method will be invoked? No. `Method.invoke()` is always invoked on a specific overloading of the method, previously selected by a call to `Class.getMethod()` or by other means. The Reflection API does not automatically choose between overloadings. How does access control apply to the invocation of the `Constructor.newInstance()`, `Method.invoke()`, `Field.get()`, and `Field.set()` methods? When one of these methods is called, the Java Virtual Machine (JVM) performs the access checks described in the Java Language Specification (6.6.1), which are usually carried out by the verifier. For example, when `newInstance()` is called, the checks made by the JVM compare the identity of the caller of `newInstance()` with the access permission and identity of the constructor being called. It is as if the caller of `newInstance()` had a statically-compiled call to the selected constructor. The access check takes into account both the accessibility of the constructor itself, and the accessibility of its class. It seems that `Method.invoke()` sometimes throws an `IllegalAccessException` when invoking a `public` method. What's going on? It is a common error to attempt to invoke an overridden method by retrieving the overriding method from the target object. This will not always work, because the overriding method will in general be defined in a class inaccessible to the caller. For example, the following code only works some of the time, and will fail when the `target` object's class is too private:
       void invokeCommandOn(Object target, String command) {
         try {
           Method m = target.getClass().getMethod(command, new Class[] {});
           m.invoke(target, new Object[] {});
         } catch ...
       }
The workaround is to use a much more complicated algorithm, which starts with `target.getClass()` and works up the inheritance chain, looking for a version of the method in an accessible class.