[
https://issues.apache.org/jira/browse/JDO-751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15146467#comment-15146467
]
Renato Garcia commented on JDO-751:
-----------------------------------
Treating it just as T on the APIs/query would require you to convert your
Optional to nullable references again in order to pass it as a parameter in a
query, and something that you want to avoid. Ideally when using Optional idiom
you don't convert it back and forwards to null, you just use your Optional ref.
I believe that proper support of Optional idiom in JDO would mean not forcing
people to write null and converting Optional values back and forward to
nullable refs.
I reckon that exposing Optional<T> as the type on the API/Query makes the
solution more consistent, regular and requires less special cases, except for
the auto de-referencing of course, which is part of the proposed solution
anyway.
In my view, there are similarities in boxing of primitives and the Optional,
however there is a key difference: When using boxing they represent the same
value, whereas "null" and "empty" are just not the same thing - you are not
wrapping null (this would equivalent to {{Optional.of(null)}} which throws an
NPE). My opinion is that this is a fundamental difference and therefore
important to keep the semantics in this scenario. On the other hand, when
querying using "null" on a Optional field, the result would be less relevant
because, again, it makes no sense when using Optional to do so (even though it
is possible in Java, guess what? Also doesn't make sense since they shouldn't
be null and being null is an error(NPE), hence no use in practice). So I think
it is reasonable that in practice for this scenario, it could either be invalid
or dependent on the underlying implementation/datastore; but again, the only
single and simple reason you'd use Optional is to replace the usage of null.
Nevertheless, if one day someone manage to use null and Optional together (kind
of a paradox?!?!), in a super clever way, I'm sure they will have a solution
that overcomes this limitation as well! :)
Regarding viewing Optional<T> as T, there are some implications such as how to
handle metadata. For instance, what {{MemberMetadata.getFieldType}} should
report? T or Optional<?> - in either case how do you represent that with type
erasure in mind and JDO metadata model keeping both types, preferably without
causing too much impact and discrepancy with existing approach.
A possible alternative would be to view Optional<T> as a container of <T>, or
simply a collection, which happens to have zero or one element only. From my
experience, in my attempts to implement an experimental support for Optional
types in DN, I found the container approach more aligned and easier to abstract
in terms of current JDO concepts/metadata; requiring less forgery - possibly
because it is closer to what it actually is being represented. Of course this
conclusion is also highly influenced by the DN implementation, but I think it
is still valid observation. It's worth noting that I think they are both valid
views after having explored both paths.
> 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)
