Ambiguous reference when invoking Properties.putAll() in Java 11

[ijuma]

Java 8:

scala> import java.util.Properties
import java.util.Properties

scala> new Properties().putAll(new Properties)

Java 9:

scala> import java.util.Properties
import java.util.Properties

scala> new Properties().putAll(new Properties)
<console>:13: error: ambiguous reference to overloaded definition,
both method putAll in class Properties of type (x$1: java.util.Map[_, _])Unit
and  method putAll in class Hashtable of type (x$1: java.util.Map[_ <: Object, _ <: Object])Unit
match argument types (java.util.Properties)
       new Properties().putAll(new Properties)

The reason is that the following override was added in Java 9 in order to use a ConcurrentHashMap as the underlying implementation:

    @Override
    public synchronized void putAll(Map<?, ?> t) {
        map.putAll(t);
    }

scalac seems to think it's an overload instead of an override. The Hashtable method is defined as (K = Object and V = Object):

    public synchronized void putAll(Map<? extends K, ? extends V> t) {
        for (Map.Entry<? extends K, ? extends V> e : t.entrySet())
            put(e.getKey(), e.getValue());
    }

I found this while trying to compile Apache Kafka with Java 9.

Is it worth doing anything about this apart from documenting it somewhere?

[ijuma]

Another somewhat subtle issue:

scala> import java.nio.ByteBuffer
import java.nio.ByteBuffer

scala> ByteBuffer.allocate(10)
res3: java.nio.ByteBuffer = java.nio.HeapByteBuffer[pos=0 lim=10 cap=10]

scala> res3.limit
<console>:15: error: ambiguous reference to overloaded definition,
both method limit in class ByteBuffer of type (x$1: Int)java.nio.ByteBuffer
and  method limit in class Buffer of type ()Int
match expected type ?
       res3.limit

The limit method was moved from ByteBuffer to the superclass Buffer and it can no longer be called without (). We may want to start a Java 9 migration notes or something.

[SethTisue]

We may want to start a Java 9 migration notes or something

I've made a jdk9 label here in the tracker

[SethTisue]

and see also the umbrella JDK 9 ticket at scala/scala-dev#139

[paulp]

Please note the first bug exists in all versions of scala/java. Java 9 just happens to hit it with the change.

// J.java
package j;

interface Bippy<A> {
  public void f(Bippy<? extends A> t);
}
class J implements Bippy<Object> {
  public void f(Bippy<?> t) { }
}

// S.scala
package j

class S {
  new J f new J
}
// a.scala:4: error: ambiguous reference to overloaded definition,
// both method f in class J of type (x$1: j.Bippy[_])Unit
// and  method f in trait Bippy of type (x$1: j.Bippy[_ <: Object])Unit
// match argument types (j.J)
//   new J f new J
//         ^
// one error found

Failing this way makes no sense because even if those types were distinct, you couldn't overload on them because they have the same erasure. But j.Bippy[_] is equivalent to j.Bippy[_ <: Any], and in Java there is no distinction between Object and Any.

We have seen overriding-as-overloading over the imaginary distinction between Any and Object in the past, most prominently that def ==(x: Any) and def ==(x: Object) were seen as overloaded methods until ~3 years ago, something which was discovered in an impressively indirect way because type inference proceeds differently when calling an overloaded method.

[ijuma]

Thanks Paul. I realise that the issue has existed for a while, but I thought it was worth pointing out that working Scala code breaks when upgrading to Java 9 due to this issue.

[paulp]

@ijuma Oh, absolutely. I know you would already have known based on the nature of the bug that it wasn't specific to java 9, and tying it to java 9 is probably the way to get it fixed, but I didn't want the overall takeaway to be that it's a java 9 bug.

[sjrd]

This issue prevents the Scala.js test suite from being compiled, with zillions of issues of the form

[error] /localhome/doeraene/projects/scalajs/test-suite/shared/src/test/scala/org/scalajs/testsuite/niobuffer/ByteBufferTest.scala:37: ambiguous reference to overloaded definition,
[error] both method position in class ByteBuffer of type (x$1: Int)java.nio.ByteBuffer
[error] and  method position in class Buffer of type ()Int
[error] match expected type ?
[error]     assertEquals(2, buf.position)
[error]                         ^

This used to compile because position(int) was not redefined in ByteBuffer. It was only defined in Buffer, alongside position(). This apparently was enough to give position() a higher priority when called as position(). But now that position(int) is redefined in a subclass, there is an ambiguity.

Writing buf.position() instead of buf.position works around the issue, but I'm not sure I want to change 85 call sites in my test suite :s I guess I have no other choice, though.

Independent reproduction:

$ ~/opt/scala-2.12.3/bin/scala
Welcome to Scala 2.12.3 (Java HotSpot(TM) 64-Bit Server VM, Java 9).
Type in expressions for evaluation. Or try :help.

scala> val b = java.nio.ByteBuffer.allocate(5)
b: java.nio.ByteBuffer = java.nio.HeapByteBuffer[pos=0 lim=5 cap=5]

scala> b.position
<console>:13: error: ambiguous reference to overloaded definition,
both method position in class ByteBuffer of type (x$1: Int)java.nio.ByteBuffer
and  method position in class Buffer of type ()Int
match expected type ?
       b.position
         ^

scala> b.position()
res1: Int = 0

scala> val c: java.nio.Buffer = b
c: java.nio.Buffer = java.nio.HeapByteBuffer[pos=0 lim=5 cap=5]

scala> c.position
res2: Int = 0

whereas on Java 8:

$ ~/opt/scala-2.12.3/bin/scala
Welcome to Scala 2.12.3 (Java HotSpot(TM) 64-Bit Server VM, Java 1.8.0_40).
Type in expressions for evaluation. Or try :help.

scala> val b = java.nio.ByteBuffer.allocate(5)
b: java.nio.ByteBuffer = java.nio.HeapByteBuffer[pos=0 lim=5 cap=5]

scala> b.position
res0: Int = 0

scala> b.position()
res1: Int = 0

scala> val c: java.nio.Buffer = b
c: java.nio.Buffer = java.nio.HeapByteBuffer[pos=0 lim=5 cap=5]

scala> c.position
res2: Int = 0

[retronym]

We have a special case in matchesType that tries to gloss over the fact that Any and AnyRef are one and the same in Java, but this is too shallow to deal with the references to the type parameters.