Actually, you can implement any interface with a block, so this is a valid message. It's just not particularly useful when the interface has many different and incompatible methods.

However, I have thought that perhaps cases like this should only coerce if there's exactly one abstract method on the likely interface. It's not something we've done formally, though.

As a workaround in the short term you can select the method you want using java_send, java_method, or java_alias. Note that when specifying interface types, you currently need to add .java_class:

class my::pkg::MyClass
  java_alias :open_file_callable, :openFile, [java.lang.String, Java::your::package::Consumer.java_class])
end

The syntax for java_method and java_send is similar.

@enebo How dangerous to compatiblity might it be if we modified Java method lookup to only coerce procs when the target interface has one abstract method? It would narrow down some ambiguous cases like this.

Pardon my inconsistent use of . and :: in Java class names. The :: form is necessary in a class statement because . is disallowed there.

Since I control the interface in this instance I could probably bump the method name on the Java side to get around it I guess... I was just trying to keep the interface as clean as possible. I also wondered whether there were an annotation to explicitly mark the methods intended to be used with blocks...

I see what you're saying though I think... the intent is to support implementing multiple overloads all going to the same block, I gather... somehow I assumed it wasn't possible to implement multiple methods with a single block.

It would be enough for me if the existence of a single abstract-method were used as a tiebreaker in this situation even if multi-method interfaces still worked in other more general situations. But I haven't taken a close look at how this part of type coercion works, so I'll let the experts decide. :)

The minimal fix for 1.7 is something like this.

The method I modified for 1.7 doesn't seem to exist anymore on master, though, which complicates things.

Edit: Okay, I see, my change depends on commit c1a174f which was part of issue #2595, which is committed to 1.7 but not master. This makes sense, since both are sort of similar, looking at the argument type and using that to disambiguate the parameter lists.

Well, tested my change on 9.0.0.0.rc1 and it doesn't work. But not only that, I looked at the code on 1.7.20 and couldn't figure out how it was working there either. So clearly it was the wrong way to do it.

But now my attention is on this bit of CallableSelector:

            // somehow we can still decide e.g. if we got a RubyFixnum
            // then (int) constructor shoudl be preffered over (float)
            if ( ambiguous ) {
                int msPref = 0, cPref = 0;
                for ( int i = 0; i < msTypes.length; i++ ) {
                    final Class<?> msType = msTypes[i], cType = cTypes[i];
                    msPref += calcTypePreference(msType, args[i]);
                    cPref += calcTypePreference(cType, args[i]);
                }
                // for backwards compatibility we do not switch to cType as
                // the better fit - we seem to lack tests on this front ...
                if ( msPref > cPref ) ambiguous = false; // continue OUTER;     // <-- ***
            }

Here it seems to have computed that the candidate preference cPref is "not worse" than the most-specific preference msPref. (I won't imply "better" because the comparison doesn't.) But then the code deliberately (according to the comment) doesn't replace mostSpecific. I haven't tested whether replacing it makes it work, but that's interesting nonetheless as it seems to mean there is no way to break the tie by the time the code gets this far.

So is the correct way to do this to define a new Matcher in the sequence between ASSIGNABLE and DUCKABLE, which matches RubyProc against a functional interface?

Attempt 2, hakanai@8ef983d

this is actually more of a "true" bug than it seems, I hoped its already fixed but its not, my notes:

• method selector (was) "non-deterministic" in cases such as ArrayIndexOutOfBoundsException when calling super of Java class #2923
• hoped that changes due improve dispatch for proc-to-iface based on arg count #3136 handle these cases as well
• ... just like they kind of did fix Ambiguous method warning when submitting a Runnable to an Executor #3263

what I'm seeing here is still non-determinism for the proc matching case (result depends on SDK's class.getMethods return order) which is why I believe it should be fixed on jruby-1_7 as well ... was actually able to get the map version to match on a few runs. will try to come up with a "deterministic" fix.

side note: we already have a functional-interface checking mechanism:

I'm rediscovering this issue now on 9.0.5.0 but I'm not sure whether it's because this time I am passing an RSpec double, whereas maybe if I passed a block it would be 100% reliable.

@trejkaz it's definitely possible that the RSpec double looks ambiguous to the JI subsystem. Running on a newer version of Java can sometimes cause this to come up due to overloads and new methods added to the core Java types. If you can narrow it down to a specific reportable oddity, please open a new issue and we'll help you look into it.