On Thu, 6 Mar 2025 03:08:58 GMT, Nir Lisker <nlis...@openjdk.org> wrote:
> I tested the new convergence check. If listener A and listener B fight over a > value, it works, but if I add after then listener C that just prints what it > sees without changing the value, it completes without an error. > > Is it not possible to let the SOE be thrown naturally (by infinite recursion)? Not without breaking one of the rules. I can't get infinite recursion if I'm not calling the change listener that is causing it. I'd have to call it either with `oldValue == newValue` (breaks Rule 2) or `badOldValue + sameNewValue` (breaks Rule 1 which is what `ExpressionHelper` does). We can of course discuss this, but I think no `ChangeListener` is interested to be called with `oldValue == newValue` in edge cases. It probably wouldn't require special logic on their parts though, so it could be considered. The nasty case of adding/removing listeners to maintain a chain like node->scene->window would not break when both values are equal. > > Note that the non-convergence detection logic is pretty smart, as the test > > case where multiple listeners are trying to agree upon a value that is > > divisible by 3, 5, 7 and 11 still works fine > > And what about non-integer values, like custom objects or strings? I fail to see how this would make a difference. The test case demonstrates what happens if multiple listeners have non-conflicting rules defined, and it is not rejected just because multiple listeners are making changes, as long as they eventually reach an agreement. Doing this with any other values should work just as well as long as there **exists** a solution (and the listeners at least make some effort to resolving it). If there is no solution, or some listeners are just resetting values back, then there is no hope that it will ever converge. So a listener that requires even values and another that requires uneven values -> no solution. A listener that requires even values and one that requires positive values -> solution possible. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1081#issuecomment-2703223673
