Updating class javafx.beans.binding.When

[Kevin Rushforth]

Sorry for the delay in responding. I was traveling when this was sent 
and barely able to keep up with urgent email / tasks.

Most of what you suggest below seems good. My only concern is whether 
the "on demand" evaluation will have any side effects. Conceptually, it 
seems like the right thing to do.

The refactoring you propose is probably best done as a separate bug fix, 
so that we don't mix behavioral changes with refactoring, unless you 
think that the refactoring is intertwined with the fix.

If you would like to work on a fix, that would be good. It will need to 
include new unit tests, plus ensuring that the existing unit tests pass.

Thanks.

-- Kevin


Nir Lisker wrote:
> Hi,
>
> I was looking at https://bugs.openjdk.java.net/browse/JDK-8089579, which
> prompted me to have a look at When. There are a few points I would like to
> address:
>
> * StringConditionBuilder#otherwise(ObservableStringValue) does not check
> for null as other condition builders do. This results in a deeper NPE
> when StringCondition tries to register a listener to the
> ObservableStringValue.
>
> * I would like a (re)evaluation on the above bug ticket and thoughts on the
> proposal of "on demand evaluation" using a Supplier or a similar method.
> The behavior of the intended implementation would be to evaluate 'then' and
> 'otherwise' whenever their condition is met, and only then.
>
> * The class can benefit from some small refactoring, such as using
> Objects.requireNonNull for null checks and some code reuse to reduce the
> chance of bugs such as the missing null check of StringConditionBuilder.
>
> * There are a few Javadoc corrections and some clarifications of the
> current behavior could be beneficial as well.
>
> I can work on all of the above. How to proceed?
>
> - Nir
>