-
Enhancement
-
Resolution: Duplicate
-
P3
-
None
-
7
-
generic
-
generic
We need to specify interactions between JSR 292 and the core reflection API.
For example, MethodHandle.class.getMethod("invokeGeneric", ...) should return a method descriptor for each possible signature, even though MethodHandle.class.getMethods() does not list all of them. (It cannot, since the list is infinite.)
New methods may be warranted, depending on details of the JSR 292 API. The Method, Constructor, and Field types should have method handle properties.
[From closed duplicate bug 6963287.]
The types MethodHandle and InvokeDynamic support signature-polymorphic calls. This needs to be suitably modeled by the Core Reflection API. Probably getDeclaredMethod needs to return a different Method for every requested set of argument types, for signature-polymorphic names.
Clearly getDeclaredMethods cannot return an infinite list of overloads.
There does not seem to be a way to specify non-default return value types.
For example, MethodHandle.class.getMethod("invokeGeneric", ...) should return a method descriptor for each possible signature, even though MethodHandle.class.getMethods() does not list all of them. (It cannot, since the list is infinite.)
New methods may be warranted, depending on details of the JSR 292 API. The Method, Constructor, and Field types should have method handle properties.
[From closed duplicate bug 6963287.]
The types MethodHandle and InvokeDynamic support signature-polymorphic calls. This needs to be suitably modeled by the Core Reflection API. Probably getDeclaredMethod needs to return a different Method for every requested set of argument types, for signature-polymorphic names.
Clearly getDeclaredMethods cannot return an infinite list of overloads.
There does not seem to be a way to specify non-default return value types.
- duplicates
-
JDK-6963287 Core Reflection API needs to be synchronized with JSR 292
-
- Closed
-
-
JDK-7012650 implement JSR 292 EG adjustments through January 2011
-
- Closed
-