On Wed, 22 Apr 2026 04:56:05 GMT, John Hendrikx <[email protected]> wrote:
>>> Also any reliance on _"if listener A was registered before listener B, then
>>> A will get called before B"_ is a horribly bad idea. Please, do not even
>>> try to suggest it. Simply do not. There is no way to ensure that ordering
>>> in any system of some major complexity.
>>
>> This is the case right now and will be after this PR.
>>
>>> My recommendation is: if You really plan to change in-place firing to some
>>> more sophisticated algorithm **do not do it**. Not in a stable production
>>> code. Recommend, inform, educate about possible side effect, alternatively
>>> add like "orderedFireXXX" methods or something, but do not change such an
>>> essential algorithm. As you can see above delegation is a simple method
>>> which allows programmers using the library to decide what is important from
>>> them and what is not. If they see problems with ordering delegation solves
>>> it. If however you will build it in, they will have no way to ensure that
>>> if they have problems with:
>>
>> I still don't get your point. This is about nested changes and that the old
>> value is misleading or simply incorrect. You talked about state consistency,
>> but currently, this can happen:
>>
>>
>> myProperty.addListener((_, oldValue, newValue) -> {
>> // Here, oldValue MIGHT not be the last set value, but the value before
>> that.
>> // Instead of A -> B -> C
>> // oldValue can be A and newValue be C. Which is very bad when you want
>> to remove/unregister the old value.
>> }
>>
>> This PR corrects that to BE consistent, so the `oldValue` will be B in this
>> example. This is consistency for me.
>
>> @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 promises that **if** an event is delivered,...
@hjohn There was a comment from Michael you may want to check. Otherwise, this
looks good IMO.
-------------
PR Comment: https://git.openjdk.org/jfx/pull/1081#issuecomment-4507311650
