1) The specification of Observable states that: "An implementation of
{@code Observable} may support lazy evaluation [...]"
It seems to me that this is an optional feature, and a user of this
API must be aware that any particular Observable implementation may
not support it, or that it chooses to
>
> As mentioned already, if we make any change in this area, it will need
> to be very well-tested, and even then we risk breaking applications.
>
I can make the change and can fix some of the tests (which will probably
mean deleting some of them since they explicitly rely on this behavior).
That's a good idea to dig into the history further. I looked through the
closed-source repo, and the behavior of calling get to validate the
observable when adding an InvalidationListener for bindings has been
there pretty much from the beginning, even before the creation of the
I agree with Nir on this point. I don't see the middle ground as being
all that useful in practice, just more complicated, and the
specification change would be odd.
So I think we either go with the proposed change (and it would need to
be well-tested), or leave it as-is, where every new
I disagree with this interpretation. Observable says
> Implementations in this library mark themselves as invalid when the first
> invalidation event occurs. They do not generate anymore invalidation events
> until their value is recomputed and valid again.
And ObservableValue says
An
The documentation of `Observable` states that "an implementation [...]
may support lazy evaluation" and that "implementations [...] should
strive to generate as few events as possible".
This seems to me like it would be within spec to fire an invalidation
event for every single change. It would
Is it possible to dig in the history of ExpressionHelper a bit further?
In git it seems limited to 9 years ago, but in JIRA I found this bug report:
https://bugs.openjdk.java.net/browse/JDK-8119521
It describes an issue where an InvalidationListener is not working
correctly (according to
I would also answer "no" to both points. This is also what the docs say.
So the question is: how likely do we think that changing this behavior will
> break existing applications?
>
That's the main question. I tested the JavaFX code with the new behavior
and some tests break immediately, though
Given that the intention of InvalidationListener was to be a
light-weight way to listen to properties without causing a binding chain
to be revalidated, it does seem reasonable to me that the listener is
only fired on the valid --> invalid transition, which is the specified
behavior, even if
