JDK-8199560: Dynamic evaluation for binding.When
kevin.rushforth at oracle.com
Thu Mar 29 01:36:51 UTC 2018
Breaking existing apps is the one thing I worried about with the
suggestion of doing it without API changes. So to summarize I think
there are three possiblities:
1. Just make the current API lazy for observables with no resource for
the developer. This seems unwise for the reasons you point out.
2. Keep the existing API, but add new When(ObservableXxxxx condition,
boolean lazyEval) constructors (we can discuss whether the default
should be eager to preserve compatibility for apps that rely on the side
effect of eager evaluation or lazy to match what many developers might
3. Something else.
Unless there is a problem implementing #2 (ignoring the default for
now), that might be the way to go. It would be good to get some opinions
about this from other developers.
Nir Lisker wrote:
> Iv'e given the idea of using existing API some thought.
> When using primitives, the evaluation is always eager. A method that
> returns a boolean (for example) will always be evaluated before it is
> passed to When, regardless of the condition value. This precludes the
> possibility of lazy evaluation in the scenario I've shown in the issue.
> When using observables, it's probably possible to do this. The
> observable's value is computed (that is, computeValue() is called)
> during the call to otherwise(...), specifically, when the invalidation
> listener WhenListener is registered on the observable. I think it's
> possible to register and deregister the listener depending on the
> condition's value. Using this approach, a developer can wrap a method
> call in an observable, as done in
> Bindings.createXxxBinding(Callable...). This is a bit of extra work
> for the developer, having to create a binding. It'll also break
> current behavior unless we do something like adding a constructor
> When(ObservableBooleanValue condition, boolean lazyEval) and default
> the current one to lazyEval=false. We could also use the "we told you
> so" line for developers who rely on the current undocumented behavior.
> - Nir
> On Sat, Mar 17, 2018 at 1:39 AM, Kevin Rushforth
> <kevin.rushforth at oracle.com <mailto:kevin.rushforth at oracle.com>> wrote:
> Conceptually what you describe sounds like a good approach to explore.
> Another approach worth exploring is to see whether this can be
> done without API change, using the existing API. I took a (very
> quick) look and didn't see anything that would preclude fixing
> this using the existing API, nor does the specification
> (javadoc-generated API docs) mandate the current behavior of
> eagerly evaluating both the "then" and "otherwise" conditions.
> Since it was only a quick look, I can't be sure.
> -- Kevin
> Nir Lisker wrote:
> I've proposed to work on a public API for binding.When that adds
> capabilities for dynamic evaluation of the 'then' and 'otherwise'
> arguments. Any comments?
> - Nir
More information about the openjfx-dev