[
https://issues.apache.org/jira/browse/JDO-751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15142722#comment-15142722
]
Tilmann Zäschke edited comment on JDO-751 at 2/11/16 1:31 PM:
--------------------------------------------------------------
??perhaps it should be also true that querying with null on an Optional has
undefined behaviour; which is not a big deal because in practice since you
shouldn't be doing it anyway and when you are using Optional this distinction
becomes irrelevant.??
I think that one of the design goals of JDOQL was to be close to Java. I think
it's already a bit problematic to introduce shortcuts that have different
semantics than Java, but I really don't think it's a good idea to intentionally
prevent simple operations (comparison of Optional to null) in JDOQL that are
possible in Java and give them different meaning in JDOQL.
On a separate note, I saw that {{Optional}} is not {{Serializable}}, and it
seems to be only intended (or useful) for lambdas/streams. I even saw someone
mentioning that they considered calling it {{OptionalReturn}} to indicate that
it should only be used as return value.
There is one thing that I would find interesting though: The semantic of
{{Optional}} means that it cannot be modified, i.e. it is an immutable
reference. Translated to a DBMS, that would mean that {{Optional}} protects a
reference such that the referenced object cannot be deleted.
In summary, I think {{Optional}} is not intended by the Java designers to be
serializable, so maybe JDO should not support this either. However, if we do
support it, I'm still somewhat opposed to shortcuts, because they change the
semantics. However I would support the non-deletability of referenced objects,
because that would be an interesting feature and would better reflect the
semantics of {{Optional}}.
was (Author: tilmann):
??perhaps it should be also true that querying with null on an Optional has
undefined behaviour; which is not a big deal because in practice since you
shouldn't be doing it anyway and when you are using Optional this distinction
becomes irrelevant.??
I think that one of the design goals of JDOQL was to be close to Java. I think
it's already a bit problematic to introduce shortcuts that have different
semantics than Java, but I really don't think it's a good idea to intentionally
prevent simple operations (comparison of Optional to null) in JDOQL that are
possible in Java and give them different semantics.
On a separate note, I saw that {{Optional}} is not {{Serializable}}, and it
seems to be only intended (or useful) for lambdas/streams. I even saw someone
mentioning that they considered calling it {{OptionalReturn}} to indicate that
it should only be used as return value.
There is one thing that I would find interesting though: The semantic of
{{Optional}} means that it cannot be modified, i.e. it is an immutable
reference. Translated to a DBMS, that would mean that {{Optional}} protects a
reference such that the referenced object cannot be deleted.
In summary, I think {{Optional}} is not intended by the Java designers to be
serializable, so maybe JDO should not support this either. However, if we do
support it, I'm still somewhat opposed to shortcuts, because they change the
semantics. However I would support the non-deletability of referenced objects,
because that would be an interesting feature and would better reflect the
semantics of {{Optional}}.
> 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)
