RFR: 8290310: ChangeListener events are incorrect or misleading when a nested change occurs [v5]

[John Hendrikx]

On Fri, 21 Feb 2025 02:55:22 GMT, Michael Strauß <mstrauss at openjdk.org> wrote:

> > I think these rules need to become part of the specification of `ChangeListener`.
> 
> If we do that, then we
> 
> 1. break many implementations that don't use the property base classes ("break" as in: render them non-compliant)
> 2. force compliant implementations to basically re-implement this PR, which is unreasonable
> 
> We should think about providing a listener management API that third parties can use to easily create compliant implementations.

The code in this PR could partially become public API.  I'd then probably also provide a simpler option that doesn't rely on an `Object` field for optimization, so users can choose to go fully optimized or (more likely) use a simpler option as it probably only matters for core FX properties.

Interfaces however can't enforce anything.  Its easy to create a non-compliant `Set` implementation (See JavaFX `BitSet`).  Such non-compliant implementations have wide ranging consequences however, as they may accidentally get exposed in public API as plain `Set`s (see Node#getPseudoClassStates -- now fixed).

That doesn't mean that interfaces shouldn't specify what a compliant implementation is.  There is already an implicit expectation as to how change listeners operate, derived from their name ("change") and their parameters ("old value", "new value").  It is reasonable to expect to be only called on a change ("old value" != "new value"); it is also reasonable to expect that the old value is what was received in the previous's call new value (this saves caching the value when you really need it).

If such values are unreliable, then there is just no point to the entire interface; you might as well use `InvalidationListener`, store your own "old value" and get the current value directly from the property.

The point of encoding these expectations in the interface is that when bugs occur, it is clear who is at fault; the user who is unable to deal with bad values, or the implementation that provides them.  So, yes, 3rd parties may become non-compliant (but only in edge cases where they were probably already broken) so nothing changes there.  With the implicit rules now spelled out it is however now easier for users to file bug reports against non-compliant implementations, not to mention, much easier for users to see that Change Listeners indeed provide what they likely already **assumed** to be true...

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1081#issuecomment-2673567634