JDK-8091393: Observable collections for ObservableMap views

[Nir Lisker]

Then maybe a solution would be around adding new methods like
observableKeySet(). These will need to be default methods, and the
implementation could test if keySet() already returns an ObservableSet, in
which case it returns it, and if not it wraps the Set in an
ObservableSetWrapper or something like that.

On Mon, May 30, 2022 at 11:50 AM John Hendrikx <john.hendrikx at gmail.com>
wrote:

> Sorry, I misunderstood, I missed that the methods weren't already
> defined in ObservableMap, so no existing signature is changed.
>
> --John
>
> On 30/05/2022 09:39, Tom Schindl wrote:
> > 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
>