Force single argument in scala varargs

Given a java class with two methods (taken from mockito):

OngoingStubbing<T> thenReturn(T value);

OngoingStubbing<T> thenReturn(T value, T... values);

If I invoke from scala with


I get an error:

Description Resource    Path    Location    Type
ambiguous reference to overloaded definition, both method thenReturn in trait OngoingStubbing of type (x$1: java.lang.Object, x$2: <repeated...>[java.lang.Object])org.mockito.stubbing.OngoingStubbing[java.lang.Object] and  method thenReturn in trait OngoingStubbing of type (x$1: java.lang.Object)org.mockito.stubbing.OngoingStubbing[java.lang.Object] match argument types (java.lang.String)

And I cannot figure out how to fix this.


These answers are all to the wrong question. The difference is subtle, but this is not the same issue as the one in the linked ticket. That one does require unreasonable gymnastics to call the non-varargs method. For this one, the following is enough.


Or, if you didn't want to do that for some reason, you don't need the type alias and the cast. You can use a structural type ascription directly.

(this: { def thenReturn[T](s: T): OngoingStubbing[T] }).thenReturn("something")

The issue here is type inference at the intersection of overloading and polymorphism - one method is more specific, but scalac doesn't figure out which. The issue in SI-2991 is genuine ambiguity due to an interaction between overloading and tuple conversion - neither is more specific.

This is a known Scala-Java interoperability problem, though it's unfortunately not in the FAQ. Here's the Scala ticket describing the problem. Essentially, both methods are applicable when you give a single argument, and the Scala compiler currently doesn't have any heuristic to decide which one is "more specific". Alexey Romanov's approach to always use the varargs version is a good workaround:

thenReturn("something", Nil: _*)

There is also a question running into a similar problem with JCommander. One of the answers there gives a clever workaround using structural types. This approach will use reflection behind the scenes, so you may or may not want to go that direction. For your use case, it would look something like:

type useSingleArgVersion = { def thenReturn(value: AnyRef): OngoingStubbing }

Finally, there is a similar question running into a similar problem with mokito. It doesn't really provide any workarounds, but it does describe the problem in a bit more detail, if you're interested in the reason this happens.

If calling the vararg version is acceptable,

thenReturn("something", Nil: _*)

Can't think of a way to call the method without varargs right now.

The workaround is quite easy:

OngoingStubbing<T> thenReturn(T value);

OngoingStubbing<T> thenReturn(T value1, T valu2, T... values);

There is no "varargs must be non empty" feature.

Assuming others will find this question when having the overloaded method value thenReturn with alternatives error, I want to share my solution as well.

Instead of


I use


which resolves the disambiguity in my case.

I tried Steve's solution and got a huge compiler error including:$TypeError: type mismatch;
 found   : scala.reflect.Manifest[Nothing]
 required: scala.reflect.ClassManifest[B]
Note: Nothing <: B, but trait ClassManifest is invariant in type T.
You may wish to investigate a wildcard type such as `_ <: B`. (SLS 3.2.10)

I was able to make it work with something like:

thenReturn("something", Seq.empty[Object]: _*)

Need Your Help

Jquery SimpleModal: what is the purpose of the container?

javascript jquery simplemodal

I am trying to use the jQuery SimpleModal plugin and I am curious about something: The description page mentions a "container" div. What is the purpose of this? Do I need to use it to use the plugin?