JDK-8241821 : Need higher quality runtime reflection data
  • Type: Enhancement
  • Component: core-libs
  • Sub-Component: java.lang:reflect
  • Affected Version: 15
  • Priority: P4
  • Status: Closed
  • Resolution: Not an Issue
  • Submitted: 2020-03-26
  • Updated: 2021-02-05
  • Resolved: 2020-03-30
Related Reports
Relates :  
JDK-8061418 - Add reification of generic type parameters to the Java programming language
Description
ADDITIONAL SYSTEM INFORMATION :
OS-indepenedent

A DESCRIPTION OF THE PROBLEM :
Currently the Class/Type system reflection is pretty limited at runtime--lots of valuable information (particularly the actual types of type parameters) are lost to erasure.  It would be highly desirable to have some mechanism that allowed this information to be available upon runtime reflection.   For example, today Thing[Integer] is the same thing as Thing[Boolean] because the type parameter values are lost.  Not required, but the Class/Type model could be cleaner, but I understand the history, so that's not vital.  Having some way to "relax" type erasure for the purposes of reflection is the ask.  Scala had done it thru the TypeTag mechanism, which frankly is a bit over-engineered but does the job.
Comments
One of the consequences of erasure is that much of the information being requested is simply not present at runtime. It's not a matter of "relaxing" erasure. The information doesn't exist, and it would be a major change to provide it. One of the ideas around generic reification (see JDK-8061418) is to provide generic type information but not to check it everywhere. This is perhaps reasonable. However, there are no plans to pursue generic reification in this form. The closest effort is Project Valhalla's generic specialization effort: http://openjdk.java.net/projects/valhalla/ http://openjdk.java.net/jeps/218 That said, some generic information is available, if it is explicit in the source. Consider a class with the following methods: public <T> List<T> m1(); public List<String> m2(); The expression SomeClass.class.getMethod("m1").getGenericReturnType() returns a Type that represents List<T>. Because of erasure (as noted above) there is no way at runtime to get the type represented by T. However, the expression SomeClass.class.getMethod("m2").getGenericReturnType() returns a Type that represents List<String>. This is possible because this information is statically compiled into the class file and is not erased. In any case, no additional information is available at runtime. Closing as Not an Issue.
30-03-2020
Move to JDK for further evaluation.
30-03-2020