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
