[
https://issues.apache.org/jira/browse/JDO-751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15155121#comment-15155121
]
Renato Garcia commented on JDO-751:
-----------------------------------
{quote}
I also think (as I mentioned earlier) properties of the underlying datastore
should ideally not affect the API too much (I guess that possibility
performance optimisations should be the main reason). After all we are writing
an OO API and staying true to the Java OO-Model makes it easier to use.
I can understand the worry about the implementation details. However, I work
with an object-database that represents the API data model (almost) 1:1. So
maybe you can understand that I would prefer not to have to deviate from the
1:1 OO representation only to make implementation in RDBMS easier.
{quote}
I totally agree, and I'm not ignoring the other datastores - In fact I'm
proposing something in the middle, which should work well with any datastore
and with the only trade-off of deviating from Java semantics in a scenario that
has no usage in practice. If you go in the other direction, you would be biased
towards datastores that can represent this seamless. Anyway, if the spec
mandates that the semantics are kept for Optional reference null checks, in
practice you would be forcing datastores that use {{null}} to also cater for
'empty' for the pure sake of useless semantics, resulting in an unnecessary
inefficiency; and most likely implementations will have a sane option where you
can choose to be non-spec compliant and not have this semantics and be more
aligned to the datastore model - which of course is what people will be using.
So why make it more complicated a make people implementing the API (myself
included here :)) waste their time supporting something that has no practical
use, when the spec could anticipate this and be more aligned to reality? Note
that you could still implement the semantics in any datastore if you choose to,
and if anyone cares about it, they just choose to use a implementation where
this is supported or contributing to the implementation with this support.
{quote}
@Renato:
I do like your proposal with viewing Optional as a collection. But I suppose
that would entail that the object referenced by the Optional can only be
accessed by get(), and that comparing Optional<Department> to a Department in
JDOQL would fail?
{quote}
Not necessarily, as I think this should still work with the "auto-conversion"
that Craig is proposing; but ideally yes, it should fail.
> 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)
