On Sat, 26 Sep 2026 17:31:19 GMT, John Hendrikx <[email protected]> wrote:
>> modules/javafx.base/src/main/java/javafx/beans/value/ObservableListValue.java
>> line 36:
>>
>>> 34: * {@link ObservableValue}. A {@code ChangeListener} registered on an
>>> 35: * {@code ObservableListValue} is notified when the contents of the
>>> list change
>>> 36: * as well as when the list reference is replaced. When the contents
>>> change, the
>>
>> I think that invoking a change listener when only the _contents_ of a list
>> has changed is a jarring defect. A change listener should only be invoked
>> when the list instance is changed; for its contents, we have
>> `ListChangeListener`. Now, I'm not sure if we can ever fix this, but maybe
>> we shouldn't enshrine this defect into specification with this PR. If we
>> come to the conclusion that it can't be changed, we can always specify this
>> behavior later.
>
> Hm, yeah, I doubt we'll ever be able to change it, and I would recommend
> deprecating them completely. But since this was already a bit out of scope
> for this PR, I can just leave this change out.
>
> A closer (unrelated) investigation also turned up that any kind of nested
> change on an `ObservableList` will break the `Change` you receive, even if
> you trigger that nested change from an invalidation or change listener (ie.
> before `ListChangeListener`s are called).
>
> So I think I would also recommend throwing a
> `ConcurrentModificationException` in those cases, because the `Change` you
> receive in a nested scenario will just be incorrect, lead to perhaps
> `IndexOutOfBoundsException`s or worse still, silent corruption as you process
> the outdated `Change`.
>
> I was checking this to see if it would at some point be useful to have
> `ListenerManager` support the collection observables, but the whole nested
> change part won't apply for those as it is disallowed (hidden on
> `ListChangeListener` but applies to all types of listeners for the collection
> observables):
>
>
> * <b>Warning:</b> This class directly accesses the source list to
> acquire information about the changes.
> * <br> This effectively makes the Change object invalid when another
> change occurs on the list.
> * <br> For this reason it is <b>not safe to use this class on a
> different thread</b>.
> * <br> It also means <b>the source list cannot be modified inside the
> listener</b> since that would invalidate this Change object
> * for all subsequent listeners.
>
>
> The "inside the listener" should really be "inside any listener on this
> observable"...
To add to this (also see my reply to Kevin), change listeners have never been
about reference eqaulity, which is why I think it is better to go for
deprecation rather than changing them to be about reference equality for the
collection types. You can already get this easily by using an
`InvalidationListener` which are built around reference equality from the
ground up.
-------------
PR Review Comment: https://git.openjdk.org/jfx/pull/1081#discussion_r4177258205
