Can't call a final method in Java base class

Hmm interesting. So just the fact that the method is final causes it to be invisible to Java integration? We should fix for 1.0.

The patch for JRUBY-814 doesn't fix this bug, but it ought to make it easier. This has got to be an easy one...just a matter of skipping final methods or not finding them or just not handling them right. I wouldn't be surprised if it weren't a one-liner somewhere.

I believe the heart of this would be solved by JRUBY-814, but the necessary code currently isn't there. The basic idea that would fix this is that the newly-generated class in this extension would extend the original Java class, and its proxy representation would extend a proxy of the base class, making that class's methods-final or otherwise-available to the new class. Because the code that handles making Ruby subclasses of Java classes is not present, the benefit of the JRUBY-814 patch is not yet seen here...but I think we could be close.

Ahh, I think I'm narrowing in on it! In all the Java support stuff, all methods are being added that are returned from getMethods. But this includes methods from superclasses. That's a separate issue, for which I'll file a bug, but I think the situation might be this...

• getMethods is used to get a class's methods
• it lists the final methods from the superclass
• but the method is not technically declared on the subtype, and so it's not supposed to be invoked against that type

So we get a situation where we've got the method handle, since it does appear in the class's hierarchy, but it isn't declared by the target class so we can't call it there. This is similar to the situation where a private inner class implements a public interface, and we try to call against the private class's version of the method instead of the interface's version, resulting in visibility errors.

I'll investigate more.

I've got it. Easy one, as you thought. The NoSuchMethodException thrown by JavaProxyClass just means that the proxy didn't define a method, which it wouldn't for final methods. So just disregard the exception and invoke the original method. Easy!

I'll submit a patch soon. Cleaning up some horrendous inefficiency in JavaProxyClass#getMethod first (it does a linear search of the methods array for every method invocation – I'll replace with a hash).

-Bill

The attached patch resolves this issue. It also includes a couple of performance tweaks, and a fix for an unreported issue I discovered while looking at JRUBY-679. (See my notes there shortly.)

The patch is only mildly hacky, so I went ahead and applied it in 3526. It still feels like a hacky patch for our too-complicated Java integration subsystem, but we won't be looking at a rewrite/redesign until after 1.0. Since it's pretty low-impact, this is a good fix for now...and we have the unit test in our suite, so it will remain fixed forever.