+1
But maybe we could add some clarifications:
"... Comparison of fields with null return null [except when compared to
'null']"
and for the operands:
!(null) = true (?)
Cheers,
Tilmann
On 08.09.2016 21:07, Michael Bouschen wrote:
Hi,
+1 changing the spec as proposed.
Regards Michael
We have discussed changing the JDO specification in a small but significant way
and I’d like to get feedback on it.
The current specification:
Navigation through a null-valued field, which would throw NullPointerException,
is treated as if the subexpression returned false. Similarly, a failed cast
operation, which would throw ClassCastException, is treated as if the
subexpression returned false. Other subexpressions or [other values for
variables might still qualify the candidate instance for inclusion in the
result set.]
Proposed specification:
Navigation through a null-valued field, which would throw NullPointerException,
is treated as if the subexpression returned null. Similarly, a failed cast
operation, which would throw ClassCastException, is treated as if the
subexpression returned null. Comparison of fields with null return null.
Arithmetic expressions with null parameters return null. Optional.get() may
return null. Optional.isPresent() is treated as !=null.
Boolean expressions with null operands:
true & null -> null
false & null -> false
true | null -> true
false | null -> null
This change aligns JDO with SQL NULL semantics and makes reasoning about JDOQL
expressions more rational.
Craig L Russell
c...@apache.org
