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 [email protected]
