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
On Thu, 19 May 2022 13:13:01 GMT, Jay Bhaskar wrote:
> This PR is new implementation of JavaEvent listener memory management.
> Issue
> [JDK-8088420](https://bugs.openjdk.java.net/browse/JDK-8088420?filter=-1)
>
> 1. Calling remove event listener does not free jni global references.
> 2. When
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
> When the size of a ListCell is changed and a scrollTo method is invoked
> without having a layout calculation in between, the old (wrong) size is used
> to calculcate the total estimate. This happens e.g. when the size is changed
> in the `updateItem` method.
> This PR will immediately resize
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 {
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
