Skip to content

Instantly share code, notes, and snippets.

@domdorn
Last active August 29, 2015 14:05
Show Gist options
  • Star 1 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save domdorn/fb504a510ffda470991b to your computer and use it in GitHub Desktop.
Save domdorn/fb504a510ffda470991b to your computer and use it in GitHub Desktop.
Problem with jOOQ and Scala
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());
}
}
[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
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
})
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
Copy link

ktoso commented Aug 17, 2014

Here's a workaround:

  // java

  public void fun(Integer a1, Object... objs) {
    System.out.println("objs = " + objs);
  }

  public void fun(Integer a1, String... objs) {
    System.out.println("STRING objs = " + objs);
  }

  {
    fun(1, "", 12);
    fun(1, "", "");
  }
  fun(1, "a", "b") // string

  //  [error] /Users/ktoso/code/akka/akka-stream/src/main/scala/akka/stream/impl/Samples.scala:11: overloaded method value fun with alternatives:
  //  [error]   (x$1: Integer,x$2: <repeated...>[String])Unit <and>
  //  [error]   (x$1: Integer,x$2: <repeated...>[Object])Unit
  //  fun(1, "a", 12) // won't compile
  fun(1, Seq("a", 12)) // obj = List(a, 12)
  fun(1, Seq("a", 12).asInstanceOf[Seq[Object]]: _*) // obj = a, obj = 12 // OK

The reason is as you noticed, funky interplay between Scala Seq/Array and Java's representation of varargs... Can't think of a better workaround at this moment.

Hope this helps.

@lrytz
Copy link

lrytz commented Aug 18, 2014

Speculating a bit, but most likely the problem is that the least upper bound of "" and 12 in Scala is Any, which does not conform to Object (see Scala type hierarchy, Object is an alias for AnyRef)

Therefore, fun(1, "", 12) fails because the vararg parameter type is Object....

This works:

fun(1, "", 12: Integer)

The type annotation will force the Scala compiler to insert a boxing conversion, and the LUB of String and Integer is Object.

@lukaseder
Copy link

@lrytz: That's very interesting. I suspect that this issue only appears when interoperating with a Java library. Is there any way to enforce or favour some implicit conversion to Object? I.e. is there anything that can be done from a library side (we already have jOOQ-Scala, a rather trivial module that contains some implicit conversions)

@ktoso
Copy link

ktoso commented Aug 18, 2014

Thanks Lukas for chiming in!
I've opened an issue to track this case: https://issues.scala-lang.org/browse/SI-8800

@lrytz
Copy link

lrytz commented Aug 18, 2014

@lukaseder: Actually, you can call it a bug in Scala's Java-interopability. Even though in Scala's type system, java.lang.Object is an alias for scala.AnyRef, when reading a classfile coming from Java, the Scala compiler maps Object to Any. Why? Probably to simplify Java interop. Discussed here on SO.

Now, the Scala compiler does NOT map Object varargs in Java classfiles to Any varargs.

public class Test {
  public void f(Object o) {
    System.out.println("obj");
  }

  public void g(Object... o) {
    System.out.println("obj...");
  }
}
scala> val t = new Test
t: Test = Test@1330b682

scala> t.f(1) // works because the Scala compiler thinks f: (Any): Unit
obj

scala> t.g(1) // Scala compiler thinks g: (AnyRef*): Unit
<console>:9: error: the result type of an implicit conversion must be more specific than AnyRef
              t.g(1)
                  ^

You can call that a bug, I guess. I added it to the ticket SI-8800.

@lukaseder
Copy link

@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

@lukaseder
Copy link

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

@lrytz
Copy link

lrytz commented Aug 19, 2014

@lukaseder: Yes, that works:

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment