On Sun, 4 Oct 2026 11:18:58 GMT, John Hendrikx <[email protected]> wrote:
>> 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. > >> Are we specifying that invalidation listeners and change listeners use the >> same equality mechanism? > > No, I think the distinction is clear: > - Invalidation is about reference identity `==` (with `String` being the only > exception, use `ObjectProperty<String>` if you want to avoid that) > - Change is about equality > > So that means if you care about identity, you really shouldn't be using a > change listener. > >> Are we ready for the upcoming value objects? > > Yes, I think so. When it comes to change listeners, we've always assumed that > the type involved is effectively immutable with a stable `equals()` (ie. > something that could be made into a value object once that lands) > >> 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. > > Arguably, `StringProperty` should have used `==` for the invalidation check > (perhaps that is still reasonable to change later). I'm fine that the > `Integer` cases will start working "correctly" (but differently) once that > lands, but that shouldn't break anybody (ie. you won't get an invalidation > anymore for a different `Integer` box that held the same value). Good. The new phrasing in the docs is clearer too. I think that you can add [JDK-8334429](https://bugs.openjdk.org/browse/JDK-8334429) to the resolved issues here, just alert Kevin because he's in the JIRA discussion there. On a side note, I would like to be able to reach a point with Valhalla's specialized generics where the `IntegerProperty` tree can be effectively replaced with the `ObjectProperty<int>` tree. We won't be able to deprecate the API, but Iast I looked, the implementation could merged. I assume that at that point we'd be able to revise the note if needed. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1081#discussion_r4177936655
