Hi,
Well the binary compat IMHO is not a problem. If your subtype overwrites
the return type of a method the compiler will inserts a bridge method:
Take this example
package bla;
import java.util.ArrayList;
import java.util.Collection;
import java.util.List;
public class Test {
public interface IB {
public Collection<String> get();
}
public interface I extends IB {
public List<String> get();
}
public class C implements I {
public ArrayList<String> get() {
return new ArrayList<String>();
}
}
}
if you look at C with javap you'll notice
Compiled from "Test.java"
public class bla.Test$C implements bla.Test$I {
final bla.Test this$0;
public bla.Test$C(bla.Test);
public java.util.ArrayList<java.lang.String> get();
public java.util.Collection get();
public java.util.List get();
}
The problem is more that if someone directly implemented ObservableMap
him/her self that it won't compile anymore. So it is a source
incompatible change.
Tom
Am 30.05.22 um 08:58 schrieb John Hendrikx:
It's not binary compatible, as changing the return type results in a new
method that compiled code won't be able to find.
See also "change result type (including void)" here:
https://wiki.eclipse.org/Evolving_Java-based_APIs_2#Evolving_API_interfaces_-_API_methods
--John
On 30/05/2022 03:22, Nir Lisker wrote:
Hi,
Picking up an old issue, JDK-8091393 [1], I went ahead and looked at the
work needed to implement it.
keySet() and entrySet() can both be made to return ObservableSet rather
easily. values() will probably require an ObservableCollection<E> type.
Before discussing these details, my question is: is it backwards
compatible
to require that these methods now return a more refined type? I think
that
it will break implementations of ObservableMap out in the wild if it
overrides these methods in Map. What is the assessment here?
https://bugs.openjdk.java.net/browse/JDK-8091393
