On Wed, 8 Jul 2026 20:52:01 GMT, Kevin Rushforth <[email protected]> wrote:
> What should we do then? Should we focus on #1081, or attempt this localized > fix? At surface level, this PR is a very small change: it captures the current value before invoking listeners, it's a one-line change. So it might seem like a pretty safe and easy fix, an easy win. However, we already know for a fact that capturing the current value doesn't ensure that the reported values are correct. It's simply not possible. This PR proposes to change listener notifications to make it work in one edge case, but it won't solve the underlying problem and fail to work in many other edge cases. How do we know that this is actually a good trade-off, given that we're dealing with core infrastructure? How do we ensure that we don't introduce regressions in cases that have been working so far, possibly only accidentally? This solution is not _correct_, at best it's _more correct_ than what we have, but still defective. I'm not against this PR in principle, and I can be convinced that _more correct_ is better than _less correct_, but it's still a defective solution compared to #1081, and one that needs quite a bit of testing. I've been bitten by something like this before: With #454, I proposed to have bidirectional bindings use invalidation listeners instead of change listeners. It seemed like a easy improvement, went through code review without problems, and just like that, we introduced a serious regression that was only discovered after release. ------------- PR Comment: https://git.openjdk.org/jfx/pull/2200#issuecomment-4919356142
