JDK-8199560: Dynamic evaluation for binding.When

[Nir Lisker]

I don't see any opinions, so should I investigate option 2?

- Nir

On Thu, Mar 29, 2018 at 4:36 AM, Kevin Rushforth <kevin.rushforth at oracle.com
> wrote:

> 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.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:
>>
>>> 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
>>>
>>> - Nir
>>>
>>>
>>
>