Problem with jOOQ and Scala

DSLWrapper.java

package helpers;

import org.jooq.DSLContext;

import java.util.Collection;

/**
 *
 */
public class DSLWrapper {

    private final DSLContext context;

    public DSLWrapper(final DSLContext context) {
        this.context = context;
    }

    public int execute(String sql, Collection<? extends Object> arguments) {
        return context.execute(sql, arguments.toArray());
    }
}

error.txt

[info] Compiling 1 Scala source and 1 Java source to /home/domdorn/lyrix/lyrix_php/playlyrix/target/scala-2.11/classes...
[error] /home/domdorn/lyrix/lyrix_php/playlyrix/app/controllers/Security.scala:54: overloaded method value execute with alternatives:
[error]   (x$1: String,x$2: org.jooq.QueryPart*)Int <and>
[error]   (x$1: String,x$2: Object*)Int
[error]  cannot be applied to (String, Long, String)
[error]       e.execute(sql, userId, uuid)
[error]         ^
[error] one error found
[error] (compile:compile) Compilation failed

jooq.scala

    val userId = 1L
    val uuid = UUID.randomUUID().toString.replace("-", "")
    val sql = "INSERT INTO sometable (userId, hash) VALUES (?, ?);"

    DB.withTransaction(conn => {
      val e = DSL.using(conn, SQLDialect.POSTGRES)
 e.execute(sql, userId, uuid) // does not work
// e.execute(sql, List(userId, uuid) : _*) // does not work either

    })

workaround.scala

      val e = DSL.using(conn, SQLDialect.POSTGRES)
      val l : java.util.ArrayList[Object] = new java.util.ArrayList[Object]()
      l.add(java.lang.Long.valueOf(userId))
      l.add(uuid)
      new DSLWrapper(e).execute(sql, l)

@ktoso: Thanks for opening that issue.
@lrytz: Interesting. I guess the g(Object...) case is really sign for a compiler bug. I wonder how type inference with generic methods plays into this kind of interoperability, i.e. when the signature is something like:

  public <T> void h(T... o) {
    System.out.println("t...");
  }

On a bytecode level, T... is really erased again to Object[], but on a language level, there is a lot of (false) type-safety and type-inference that is applied. I'm saying false, because any list of parameters will be viable, in principle.

This becomes particularly interesting when the T type has side-effects on the call site, such as:

  public <T> T h(T... o) {
    System.out.println("t...");
    return o != null && o.length > 0 ? o[0] : null;
  }

I wonder if this would produce the same behaviour in Scala as in Java, e.g. (pseudo-repl):

scala> 1 == t.h(1)
true

I've also copied my comment over to SI-8800

@lukaseder: Yes, that works:

scala> t.h(1) == 1
t...
res1: Boolean = true