On Sat, 26 Sep 2026 17:09:03 GMT, John Hendrikx <[email protected]> wrote:
>> modules/javafx.base/src/main/java/javafx/beans/value/ObservableValue.java
>> line 89:
>>
>>> 87: * invalidate when the new value is equal to the previous value
>>> but not the
>>> 88: * same reference; primitive and {@code String} properties
>>> compare by value.
>>> 89: * Bindings invalidate when one of their dependencies is
>>> invalidated.
>>
>> I think that you're resolving
>> [JDK-8334429](https://bugs.openjdk.org/browse/JDK-8334429) here.
>
> Yeah, I think so too, shall I add that issue to the PR or do you think it
> needs more work in other places?
The surface are of that issue is rather small (but the impact is large), so I
don't think it affects other places. We just need to be sure we're specifying
the right thing.
* Are we specifying that invalidation listeners and change listeners use the
same equality mechanism?
* Are we ready for the upcoming [value
objects](https://openjdk.org/jeps/401#Comparing-value-objects)?
> The == operator and the equals method will often produce the same results
for value objects. For some value classes, however, instances may be
interchangeable (i.e., equals) even if their field values are different (i.e.,
not ==). **To test whether two value objects represent the same value, use the
equals method. When declaring a class, define equals in a way that always
returns true for interchangeable instances.**
We probably still want `==` for them, so I think that we're still doing the
right thing.
* `ObjectProperty<String>` and `StringProperty` use different equality
mechanisms currently, which can be very confusing. This is also true with the
`Integer` case (and other numbers), but since `Integer` will become a value
object eventually, `==` will start returning `true` on cases that were `false`
previously.
-------------
PR Review Comment: https://git.openjdk.org/jfx/pull/1081#discussion_r4157077825
