JDK-8213465 : Type variable information is not always maintained for anonymous classes
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.lang:reflect
  • Affected Version: 8,11
  • Priority: P4
  • Status: Resolved
  • Resolution: Cannot Reproduce
  • OS: generic
  • CPU: x86_64
  • Submitted: 2018-11-05
  • Updated: 2021-12-14
  • Resolved: 2021-12-14
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other
tbdResolved
Related Reports
Relates :  
Description
A DESCRIPTION OF THE PROBLEM :
Type variable information is not always maintained for anonymous classes 

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Run the source code

ACTUAL -
T
null

---------- BEGIN SOURCE ----------
public class Xx<S> {

    public static <T> void main(String[] args) {
        printIt(new Xx<T>() {}.getClass());

        Runnable r = () -> printIt(new Xx<T>() {}.getClass());
        r.run();
    }

    static void printIt(Class<?> cl) {
        ParameterizedType pt = (ParameterizedType) cl.getGenericSuperclass();
        System.out.println(pt.getActualTypeArguments()[0]);
    }
}

---------- END SOURCE ----------

FREQUENCY : always



Comments
this bug can't be reproduced in JDK18
14-12-2021

[~vromero] can you describe why `Class::getGenericSuperclass` returns different result when the caller of invoking Xx::printIt is different? One reason why they are different that I can think of is that the implementation of Class::getGenericSuperclass calls caller-sensitive methods. JVM_GetCallerClass does not skip hidden classes. I do not see any CSM is called by Class::getGenericSuperclass.
09-08-2019

At this stage JDK-8171335 makes no difference to the behaviour. And I don't think it is relevant. There is no new thread involved in the test case, the difference is simply in the anonymous class when defined in the context of a lambda expression versus being defined directly in the context of another class. This has the same behaviour: public static <T> void main(String[] args) { Runnable r = new Runnable() { public void run() { printIt(new Xx<T>() {}.getClass()); } }; r.run(); r = () -> printIt(new Xx<T>() {}.getClass()); r.run(); } The issue I think is the nature of the enclosing class. In the lambda case the enclosing class is a VM anonymous class (not to be confused with a Java-level anonymous class); or with JDK-8171335 it is a non-findable class. I think it is the "hidden" nature of the enclosing class that causes the problem though I can't see exactly where this occurs.
11-12-2018

this issue could be affected by JDK-8171335, so it seems sensible waiting until JDK-8171335 is fixed
08-12-2018