@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.

@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