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
expect).
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.
-- Kevin
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.rushfo...@oracle.com <mailto:kevin.rushfo...@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:
Hello,
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?
https://bugs.openjdk.java.net/browse/JDK-8199560
<https://bugs.openjdk.java.net/browse/JDK-8199560>
- Nir
