[ https://issues.apache.org/jira/browse/JDO-751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15146301#comment-15146301 ]
Craig L Russell commented on JDO-751: ------------------------------------- I'd suggest we consider a field of type Optional<T> to be of type T in the JDOQL and persistence domains. This is quite similar to some automatic behavior in Java where a field of type Integer is auto-(un)boxed where an int is required. Even though the semantics of non-null database fields are identical to int, and null database fields are identical to Integer, we allow mapping either way. In JDOQL we don't require explicit checking for null-valued fields. Dereferencing a null-valued database field results in disqualifying the JDOQL clause, not throwing an exception. The example in JDOQL person.address.postCode == foo is instructive. The persistent field address is declared as Optional<Address>. For the purposes of this discussion, it doesn't matter whether Address is mapped as first class or second class. If we use strict Java semantics in JDOQL, we have (person.address.isPresent() && person.address.get().postCode == "2BRN2B"). Very similar to what we rejected in JDOQL to handle nulls: (person.address!=null && person.address.postCode == "2BRN2B"). Usability is the reason we rejected this and opted for the simpler person.address.postCode == "2BRN2B". Do we plan to add streams/lambdas to JDOQL? How about executing user-defined (domain) methods in the datastore? I think that there will be many more issues than Optional if/when we get to these features. @Tilmann: How do we treat Optional<Optional<Department>> where department is null? Should JDOQL do double-auto-dereferencing? I would disallow Optional<Optional<Department>>. @Renato: What would be the type of the parameter for a variable in a query? From what I understand it would be T to be consistent with accepting null? Yes, the parameter would be of type T for parameters. The parameter could be null or non-null. > Support for Java8 Optional > -------------------------- > > Key: JDO-751 > URL: https://issues.apache.org/jira/browse/JDO-751 > Project: JDO > Issue Type: New Feature > Components: specification, tck > Reporter: Andy Jefferson > > java.util.Optional provides a feature that is available in other languages. > Since JDO 3.2 will be for Java8+ then it makes sense to add support for this > as a "supported persistable type" -- This message was sent by Atlassian JIRA (v6.3.4#6332)