JRuby ambiguous methods

I am using JRuby as a part for a fast scripting within a VertX-Application, but I struggle a bit with the completion-callbacks of the Vertx-Future:

i.e.

    def process(connection) # connection is a io.vertx.sqlclient.SqlConnection
      tx = connection.begin()  
      tx.onComplete( -> succ {
        if (succ.failed()) 
          msgFailed(result.cause())
        else
          processChangeUserLanguage(connection)
        end
      })
    end

tx is a Java-Class https://vertx.io/docs/apidocs/io/vertx/core/Future.html tx.onComplete take one parameter https://vertx.io/docs/apidocs/io/vertx/core/Handler.html

But JRuby signals

warning: multiple Java methods found. Choosing onComplete(io.vertx.core.Handler)

Basically currently it uses the right definition and everything is working. Is there a way to define or stick the "succ" lambda callback to the io.vertx.core.Handler class?

thx Nik

I haven't reproduced your warning, but I'm going to guess that it's related to the fact that the VertX Future interface actually has two onComplete methods: one that takes a single handler (which is the one you're presumably trying to use) and another utility wrapper that takes two handlers and calls the first one on success and the second one on failure.

I'm not 100% sure why JRuby thinks this situation is ambiguous: you're clearly passing in a single lambda, and there's no block after the method call that could be interpreted as you attempting to pass a proc as a second argument via closure conversion. It might even be a bug in JRuby's method resolution.

In any case, one (somewhat ugly but reliable) way to get rid of the warning and to force the correct method to be called would be to use java_send:

      tx.java_send(:onComplete, [io.vertx.core.Handler], -> succ {
        # ...
      })

Alternatively, you could try replacing the lambda with just a block:

      tx.onComplete do |succ|
        # ...
      end

Mind you, I have no idea if this change will actually accomplish anything or if it'll just generate the same warning you had before. But if the warning is indeed somehow related to closure conversion, it might be enough to get rid of it.