JDK-8216196 : No visibility bridges are created for generic methods
  • Type: Bug
  • Component: tools
  • Sub-Component: javac
  • Affected Version: 8,9,10
  • Priority: P4
  • Status: Resolved
  • Resolution: Duplicate
  • OS: generic
  • CPU: generic
  • Submitted: 2019-01-05
  • Updated: 2019-06-10
  • Resolved: 2019-06-10
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.
JDK 11
11Resolved
Related Reports
Duplicate :  
Relates :  
Relates :  
Description
javac is normally adding visibility bridges for methods if they are public but declared by a package-private class:

/* package-private */ class SuperClass {
  public Object foo() { return null; }
}
public class SubClass extends SuperClass { }

This is not the case if a method has a generic type:

/* package-private */ class SuperClass<X> {
  public X foo() { return null; }
}
public class SubClass extends SuperClass<Void> { }

As a result, reflective access of this method fails with an IllegalAccessException if the following code is run from outside the package of SuperClass and SubClass:

SubClass.class.getMethod("foo").invoke(new SubClass());

I would expect javac to create a visibility bridge for the method in question to allow for reflective access.
Comments
Duplicate of JDK-8133247. No plans to backport to 8.x.
10-06-2019

This bug is a duplicate of JDK-8133247 which is fixed by an enhancement task JDK-8203488 in JDK11 build 16.
18-01-2019

I have refined the problem description. The problem really is that javac does not add a visibility bridge for SubClass what can be easily validated using javap. It does so if the method is not generic. As a result, the generic method cannot be called from outside the package using reflection despite it being public (since reflection asserts that the declaring class - SuperClass - is not visible which is however incorrect.) This bug seems to be fixed in Java 11 but affects Java 11 runtimes if code was compiled with a Java 8 version of javac.
17-01-2019

[~winterhalter] : Issue is not reproducible with the test case explained in the bug. Please attach the right test case and update the affected version in the bug.
17-01-2019