-
Bug
-
Resolution: Unresolved
-
P4
-
8
There is an outstanding problem with generic type signatures and type annotations, in that javac doesn't generate either with synthetic/mandated parameters taken into account. At least the latter (type annotations) is an outstanding javac bug.
This causes an issue that when there are synthetic/mandated parameters, getGenericParameterTypes() returns a *different sized* array depending on whether or not generic information is present. This affects getAnnotatedParameterTypes similarly. The array returned from getParameterTypes() /always/ contains synthetic/mandated parameters.
The behavior profile is as follows:
If generic signatures exist in the class file:
1) getGenericParameterTypes returns an array without synthetic/mandated parameters
2) getAnnotatedParameterTypes returns an array of AnnotatedTypes without synthetic/mandated parameters, the annotations are on the correct parameter.
If generic signatures do not exist in the class file:
1) getGenericParameterTypes returns the same result as getParameterTypes (which contains synthetic/mandated parameters)
2) getAnnotatedParametertypes returns an array of AnnotatedTypes with synthetic/mandated parameters represented, but the annotations will be on the wrong parameter in some cases (this is due toJDK-8029012)
A root cause of these problems is that there is no general way to tell whether a given parameter is a formal parameter, or is a synthetic or mandated parameter, and thus there is no general way to map between the formal parameters and the actual parameters.
This, in turn, makes it extremely difficult to fix issues likeJDK-8055063, and makes a perfect fix impossible, because it is not generally possible to know whether a given parameter is synthetic/mandated or not.
Note: this could be fixed completely by having javac generate generic signatures that also contain information about synthetic and mandated parameters.
Additionally, some aspects of the reflection API (Parameter.getAnnotatedType()) on a receiver parameter currently cannot be implemented properly.
This causes an issue that when there are synthetic/mandated parameters, getGenericParameterTypes() returns a *different sized* array depending on whether or not generic information is present. This affects getAnnotatedParameterTypes similarly. The array returned from getParameterTypes() /always/ contains synthetic/mandated parameters.
The behavior profile is as follows:
If generic signatures exist in the class file:
1) getGenericParameterTypes returns an array without synthetic/mandated parameters
2) getAnnotatedParameterTypes returns an array of AnnotatedTypes without synthetic/mandated parameters, the annotations are on the correct parameter.
If generic signatures do not exist in the class file:
1) getGenericParameterTypes returns the same result as getParameterTypes (which contains synthetic/mandated parameters)
2) getAnnotatedParametertypes returns an array of AnnotatedTypes with synthetic/mandated parameters represented, but the annotations will be on the wrong parameter in some cases (this is due to
A root cause of these problems is that there is no general way to tell whether a given parameter is a formal parameter, or is a synthetic or mandated parameter, and thus there is no general way to map between the formal parameters and the actual parameters.
This, in turn, makes it extremely difficult to fix issues like
Note: this could be fixed completely by having javac generate generic signatures that also contain information about synthetic and mandated parameters.
Additionally, some aspects of the reflection API (Parameter.getAnnotatedType()) on a receiver parameter currently cannot be implemented properly.
- blocks
-
JDK-8058220 (reflect) no type annotations on a Parameter representing the annotated receiver
- Open
-
JDK-8055063 Parameter#toString() fails w/ AIOOBE for ctr of inner class w/ generic type
- Resolved
- relates to
-
JDK-8213329 Normalize inclusion of non-explicit parameters in JVM attributes
- Open