On Wed, 2011-07-20 at 22:16 +1000, David Holmes wrote: > 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?
Hi David, Thanks for looking at my suggestion. Firstly, let me correct myself: where I originally talked about 'isSingleMethod', I actually meant 'getSingleMethod' (which returns 'null' if the given interface does not represent a single method). I believe you're right that all interface methods are currently always abstract. Therefore, please find below an updated suggested fix, which removes the duplicated check. Can I interest a core-libs committer in helping me to get this change committed? Thanks, Neil -- Unless stated above: IBM email: neil_richards at uk.ibm.com IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU # HG changeset patch # User Neil Richards <[email protected]>, <[email protected]> # Date 1311156497 -3600 # Branch ojdk-131 # Node ID e5e3c6df9f8b37e936c9cb00982c1cb92751f87e # Parent 8bbea505b060fc7c97d9c241f8531a2a758cbe20 Summary: Make getSingleMethod() agnostic of ordering of methods returned from Class.getMethods() Contributed-by: <[email protected]> diff --git a/src/share/classes/java/lang/invoke/MethodHandleProxies.java b/src/share/classes/java/lang/invoke/MethodHandleProxies.java --- a/src/share/classes/java/lang/invoke/MethodHandleProxies.java +++ b/src/share/classes/java/lang/invoke/MethodHandleProxies.java @@ -246,8 +246,9 @@ Method sm = null; for (Method m : intfc.getMethods()) { int mod = m.getModifiers(); - if (Modifier.isAbstract(mod)) { - if (sm != null && !isObjectMethod(sm)) + if (!isObjectMethod(m)) { + // NB: All interface methods are inherently abstract + if (sm != null) return null; // too many abstract methods sm = m; }
