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

[John Hendrikx]

On Wed, 12 Mar 2025 00:33:14 GMT, Nir Lisker <nlisker at openjdk.org> wrote:

> > I'm unsure what you are saying here. The common divisor example would not log a warning if I place the warning log in the same location as the SOE.
> 
> If you replace the thrown error/exception with logging then the code path will continue. What behavior will we get instead? The one before the modification where "first listener wins"?

Yeah, if there's disagreement, then the listener earliest in the chain (if it is persistent) will win, and one of the disagreeing listeners (after setting a value) will not have been notified of that change (as it was changed back).  Note that there's no inconsistency here; after all notification loops complete, the last received new value will match the current value of the property.  This goes for **all** listeners, regardless of disagreements.  In other words:

         (obs, ov, nv) - {
               // new value received here is ALWAYS going to be correct after the full notification completes

               // There is no guarantee that after calling set(X) that the value actually will become X (there
               // never was such a guarantee, also not with ExpressionHelper as other listeners can interfere
               // at any time).  So if you didn't receive a new value X, it hasn't actually become X.
               property.set(X);  
               
               // Calling this afterwards could allow you to see that your change was "rejected"
               if (property.get()  != X) {}
         }
         
Realistically, there's not really that much wrong with this.  It is just that listeners should not make assumptions that a value passed to `property.set` will become the final state.  The only way to be sure is to have received a call back with that value as the new 
value.

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

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