On Thu, 21 May 2026 10:40:38 GMT, Marius Hanl <[email protected]> wrote:
>>> @Maran23 >>> >>> My point was, that events broadcasting strategy is a critical point of the >>> system which is build around event oriented programming and model-observer >>> design. A system which exists for about thirty years now and is deployed in >>> millions of places. Touching it should be done with absolute care and >>> attention. >> >> This was done with care and attention, and fixes real problems with systems >> relying on correct old values (like listener removal). The current state of >> affairs is that the old value is unreliable in scenario's that can arise >> when notifications trigger further notifications which may unwittingly lead >> to a re-entrant call. >> >>> I wished to make an impression, that what one person sees as an obvious >>> benefit may be a complete drama for others. And this is obviously a mission >>> critical point. It should not be touched to make it better. An alternative >>> method shall be provided, the old might become deprecated, but such a >>> critical subsystem shall not change its behavior. >> >> If you have a problem with these changes, then feel free to test and refute >> what is done here. Your statement applies to any change, no matter how >> insignificant, however, what matters here is whether it aligns with what >> guarantees are made in the documentation. Anything beyond that is relying on >> undefined behavior. >> >>> My second observation was, that if one really needs proper ordering of >>> events, one may resort to `invokeLater` or override some methods. >> >> We're not changing the order of events. Events were always delivered in >> order of registration. Even though this is unspecified, it is something we >> do not wish to touch as that was deemed to be far too risky to change. It is >> sort of implied by the fact that we're talking about listener lists, and the >> fact one can register (and must remove) multiple instances of the same >> listeners. >> >>> Consistency depends on point of view. >> >> Sure. In this case it depends on what guarantees are given in the >> documentation's point of view. >> >>> For an example, can you give a warranty that in any nested condition when >>> event is fired, and the firing method returns, regardless if it was a >>> nested firing or not, that specific event was delivered to listeners? If >>> not, it will be a critical change, as a delivery time consistency becomes >>> broken. >> >> No such guarantees were given before, and none are part of the >> specification. Relying on any specific change notifications order or timing >> is undefined behavior. >> >> This PR however prom... > > @hjohn There was a comment from Michael you may want to check. Otherwise, > this looks good IMO. @Maran23 I can take a look (I assume you mean https://github.com/openjdk/jfx/pull/1081#issuecomment-3968231835) -- I think however we need a more compelling reason to get this merged (like a broken test in current FX related to some complex property interaction), otherwise I don't see this happening. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1081#issuecomment-4508888519
