RFR: 8210943: Hiding of inner classes not resolved properly

[Attila Szegedi]

The relevant Dynalink algorithm processes the class before moving on to superclass, so Hannes fix is correct in that we won’t stomp over a subclass’ inner class (inserted into the map earlier) with the superclass’ inner class (encountered later by the algorithm). So yeah, getClasses() doesn’t specify an order, but the Dynalink code has a subclass-towards-superclass traversal order.

Attila.

> On 2018. Dec 1., at 7:13, Sundararajan Athijegannathan <sundararajan.athijegannathan at oracle.com> wrote:
> 
> Class.getClasses() javadoc does not mention anything about order of classes returned.
> 
> https://docs.oracle.com/javase/10/docs/api/java/lang/Class.html#getClasses()
> 
> Do we need a check using Class.getDeclaringClass() or do I something here?
> 
> Thanks,
> -Sundar
> 
> On 30/11/18, 4:44 PM, Attila Szegedi wrote:
>> +1. Thanks for fixing this.
>> 
>>> On 2018. Nov 29., at 18:01, Hannes Wallnöfer<hannes.wallnoefer at oracle.com>  wrote:
>>> 
>>> Please review:
>>> 
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8210943
>>> Webrev: http://cr.openjdk.java.net/~hannesw/8210943/webrev.00/
>>> 
>>> AccessibleMembersLookup#lookupAccessibleMembers adds all nested classes returned by Class.getClasses(), but these may contain inherited classes that are shadowed and thus not visible from the current class. The solution is to make sure we use the first inner class with any given name.
>>> 
>>> Thanks,
>>> Hannes