basically boils down to having some-form of static Java checks in a dynamic language (Ruby).
at the time you include the interface its methods aren't implemented (and might actually never be - that is fine in a dynamic language). when the proxy is generated there might be some room for args checking and maybe issuing a warning, that might be useful to some extend - also slightly tricky to get right since in some cases dispatch reaches method_missing and you might not have all of the methods implemented and if you do there's no way knowing which will be actually used (called) so we might warn too much ...

as for the stack-trace could you please clarify what you mean.
doubt JRuby wants to switch trace type based on what calls triggered the issue.

@kares yes, this does seem hard to get right. The thing is, it is a bad user experience at the moment because JRuby quite confidently tells you you have an args issue at a given line, when the problem is really somewhere else.

I don't know if there is an efficient easy way to solve this. It would be nice if possible however.

The current stack, roughly speaking, is RrubyMethod(A) -> JavaMethod(B) -> RubyMethodThatIncorrectlyImplementsJavaInterface(C).

The error message today makes it seem like A is where the bug is, when the real problem is somewhere between B and C

I feel like the real problem here is that we have no context for the failed call, because the dispatch logic for the Ruby-based interface impl doesn't insert any context. It's a sort of hidden method_missing dispatch happening under the covers, but since it's implemented in "native" code it doesn't show up in the Ruby trace.

The dispatch logic here could perhaps be improved to provide a better error, perhaps something like "interface method SomeIfc.someMethod was not implemented in class SomeRubyClass".

@headius that error message would have been amazing here :)

It occurs to me there's a slight snag with my approach: we still need method_missing to work properly. So...

1. We can't rescue every dispatch-related error here and rewrite them, nor would we want to in case they're part of someone's (weird) API.
2. We can't do dispatch much differently since we need to attempt method_missing, which then leads back to 1.

What we might be able to do is create a new call site type specifically for interface dispatches that follows method_missing protocol:

• Use respond_to? and respond_to_missing? to check for the existence of an appropriate method target. Dispatch if found. Name overloading will potentially mean multiple searches here, so it would be worth getting invokedynamic involved.
• If those fail, check for a user-defined method_missing. Dispatch if found, and then it's out of our hands.
• If there's no user-defined method_missing, we use our own version that reports a better error but still raises the same exception type.

Tricky but doable.

A similar issue is documented in #6335. The case here is slightly different, since we are simply not defining the expected interface method on the generated class, but the basic cause (arity check happens during call plumbing and not inside the method) is the same.