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.athijegannat...@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.wallnoe...@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
