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 > > > -- Michael Bouschen akquinet tech@spree GmbH Bülowstraße 66 • D-10783 Berlin Tel: +49 30 235520-33 Fax: +49 30 217520-12 E-Mail: michael.bousc...@akquinet.de <mailto:michael.bousc...@akquinet.de> Web: www.akquinet.de <http://www.akquinet.de/> Geschäftsführung: Martin Weber, Dr. Torsten Fink Amtsgericht Berlin HRB 86780 • USt.-Id. Nr.: DE 225 964 680 [Facebook] <http://www.facebook.com/akquinet> [XING] <https://www.xing.com/companies/akquinetag> [G+] <https://plus.google.com/b/111054946250796705170/+akquinet/posts> [LinkedIn] <https://www.linkedin.com/company/akquinet-ag> [Twitter] <https://twitter.com/akquinet>
