On Wed, 11 Jan 2023 11:11:09 GMT, John Hendrikx <jhendr...@openjdk.org> wrote:
> Should I expect x here to be unreferenced? No, that's how properties work, b > will keep its reference to x. No, x is not dereferenced. But you should expect that a is no longer referencing b, but both a and b are referencing x. But I don't see your point - it's worth mentioning, when you bind a ListProperty A, to another ListProperty B, then A doesn't get the value "B", but the value will be the value of the property B. If you think the PR creates an unwanted behavior, I would appreciate seeing a **unit-test** for it, because it's way easier to discuss on the basis of a test. Making tests for memory behavior (both for being collectible and being not-collectible) is easy with JMemoryBuddy, which I wrote exactly for this use case. I'm also happy with an alternative solution - which makes the tests green, which I've provided. I'm not really opinionated. > IMHO there is a conflict between the property-like behavior of ListProperty > and the list-like behavior of the ObservableList that it wraps. On the one > hand, a list property is a reference to a list, and on the other hand, we > expect it to behave as only referring to the contents of the list. The > property like behavior that it inherits (perhaps it shouldn't have done that) > has been subverted in that adding a change listener will pretend that a > change to the list is the same as replacing the entire list object, so it is > not quite a property any more. Yes, I agree. I think - it's a complicated topic. I don't want to discuss any details, because I just want to add a fundamental bug, without discussing the whole Property/Collection design. ------------- PR: https://git.openjdk.org/jfx/pull/689
