Request for review: Make MethodHandleProxies.isSingleMethod() agnostic of ordering of methods returned from Class.getMethods()

David Holmes David.Holmes at
Wed Jul 20 12:16:38 UTC 2011

Hi Neil,

Neil Richards said the following on 07/20/11 20:51:
> java.lang.invoke.MethodHandleProxies.isSingleMethod(Class<?> intf)
> returns a boolean indicating whether the provided interface has only one
> defined method upon it.
> When making this consideration, it tries not count any method defined on
> the interface that is also defined by java.lang.Object (and so will
> always be there for all implementations of the interface).
> Because of this, for example, isSingleMethod should return 'true' for
> java.util.Comparator, which has two defined methods - compare() and
> equals() - as all but one of these methods are also defined by
> java.lang.Object.
> isSingleMethod() makes the consideration my iterating through the array
> of Method objects returned from Class.getMethods().
> The API javadoc for Class.getMethods() [1] says (amongst other things):
> "The elements in the array returned are not sorted and are not in any
> particular order." 

Indeed and this order even changed during JDK7 development.

> However, isSingleMethod() currently relies upon any methods defined on
> java.lang.Object appearing in the list before any others.
> I suppose this happens to be the case currently (at least, when using
> hotspot), but it is a generally brittle assumption for this code to rely
> upon.

I don't know if the author actually made that assumption or whether the 
code just happens to only work in that case, but it is certainly broken 

> Please find below a suggested change which removes this assumption by
> making the algorithm agnostic to the ordering returned by
> Class.getMethods().

I agree that the suggested change fixes the problem.

However, unless I'm missing something subtle, why do we need to check 
for the method being abstract? Aren't all interface methods always 
implicitly abstract?

> Please consider this change for committal.

I'll let one of the libs team file a bug :)

David Holmes

> Thanks,
> Neil
> [1]

More information about the core-libs-dev mailing list