[jira] [Commented] (JDO-751) Support for Java8 Optional
[
https://issues.apache.org/jira/browse/JDO-751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15144286#comment-15144286
]
Renato Garcia commented on JDO-751:
---
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?
Wouldn't it still be dereferencing Optional instead of nulls, given that the
actual type of the field is Optional and the JDOQL reflects the Java model
and not the datastore model?
In general Optional like classes (scala.Option, guava's Optional) are an
alternative approach to represent nullability, where you don't use {{null}} in
your code, so ideally this should be extended to the query and not force people
to use {{null}} for querying. They are not interchangeable and you shouldn't
mix them - You either use one or the other. Therefore, querying with {{null}}
when using Optional is conceptually wrong, and I guess making this the
recommended/official way just seems odd... What about datastores that can store
Optional and keep it's empty/null distinction? I believe that how it is mapped
to the datastore should be an implementation detail.
If there will be no support for methods (although I think that methods would
make the query more expressive), then just using variables would suffice by
passing an {{Option.empty()}} as parameter to query for "empty" and {{
Optional.of(value) }} for value, so no special cases.
> 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)
[jira] [Comment Edited] (JDO-751) Support for Java8 Optional
[
https://issues.apache.org/jira/browse/JDO-751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15144286#comment-15144286
]
Renato Garcia edited comment on JDO-751 at 2/12/16 9:10 AM:
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?
Wouldn't it still be dereferencing Optional instead of nulls, given that the
actual type of the field is Optional and the JDOQL reflects the Java model
and not the datastore model?
In general Optional like classes (scala.Option, guava's Optional) are an
alternative approach to represent nullability, where you don't use {{null}} in
your code, so ideally this should be extended to the query and not force people
to use {{null}} for querying. They are not interchangeable and you shouldn't
mix them - You either use one or the other. Therefore, querying with {{null}}
when using Optional is conceptually wrong, and I guess making this the
recommended/official way just seems odd... What about datastores that can store
Optional and keep it's empty/null distinction? I believe that how it is mapped
to the datastore should be an implementation detail.
If there will be no support for methods (although I think that methods would
make the query more expressive), then just using variables would suffice by
passing an {{Option.empty()}} as parameter to query for "empty" and
{{Optional.of(value)}} for value, so no special cases.
was (Author: rgarcia):
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?
Wouldn't it still be dereferencing Optional instead of nulls, given that the
actual type of the field is Optional and the JDOQL reflects the Java model
and not the datastore model?
In general Optional like classes (scala.Option, guava's Optional) are an
alternative approach to represent nullability, where you don't use {{null}} in
your code, so ideally this should be extended to the query and not force people
to use {{null}} for querying. They are not interchangeable and you shouldn't
mix them - You either use one or the other. Therefore, querying with {{null}}
when using Optional is conceptually wrong, and I guess making this the
recommended/official way just seems odd... What about datastores that can store
Optional and keep it's empty/null distinction? I believe that how it is mapped
to the datastore should be an implementation detail.
If there will be no support for methods (although I think that methods would
make the query more expressive), then just using variables would suffice by
passing an {{Option.empty()}} as parameter to query for "empty" and {{
Optional.of(value) }} for value, so no special cases.
> 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)
[jira] [Commented] (JDO-751) Support for Java8 Optional
[ https://issues.apache.org/jira/browse/JDO-751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15144287#comment-15144287 ] Renato Garcia commented on JDO-751: --- Regarding "shortcuts", I don't see why they change semantics? Aren't they just syntax sugar? I do think that more thought should be put into it though. > 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)
[jira] [Commented] (JDO-751) Support for Java8 Optional
[
https://issues.apache.org/jira/browse/JDO-751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15144474#comment-15144474
]
Tilmann Zäschke commented on JDO-751:
-
I think there still is a problem when writing {{postcode == null}} in a query.
If {{postcode}} is of type {{Optional}} and the {{Optional}} references
{{null}}, should the query match the object (because the Optional references
null) or not (because the reference to the optional is not null)? In Java this
is not ambiguous.
> 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)
[jira] [Commented] (JDO-751) Support for Java8 Optional
[
https://issues.apache.org/jira/browse/JDO-751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15144485#comment-15144485
]
Tilmann Zäschke commented on JDO-751:
-
I don't think querying for {{null}} is conceptually wrong. It would be wrong if
{{Optional}} would be a property of a reference, but it's not a property, it's
an own class/type. If we don't want people to query for 'null' then we should
make sure that they can't and forbid it. But I don't think that would be a good
idea. In Java the semantic is clearly that a reference to Optional is distinct
from a reference from Optional to something else. I'm not convinced that a
JDOQL should behave different here.
> 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)
[jira] [Commented] (JDO-751) Support for Java8 Optional
[ https://issues.apache.org/jira/browse/JDO-751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15144507#comment-15144507 ] Renato Garcia commented on JDO-751: --- You shouldn't have null references when using Optional, it defeats the purpose of the whole thing, otherwise you would need to check the reference to the Optional and then check the value of the 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)
[jira] [Commented] (JDO-751) Support for Java8 Optional
[ https://issues.apache.org/jira/browse/JDO-751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15144516#comment-15144516 ] Renato Garcia commented on JDO-751: --- In case we would like to make it not ambiguous in JDOQL how would this be implemented in a RDBMS for instance? How is this related to the "shortcuts" changing semantics, as in "shorcuts" meaning auto dereference of Optional fields? > 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)
[jira] [Commented] (JDO-751) Support for Java8 Optional
[ https://issues.apache.org/jira/browse/JDO-751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15144519#comment-15144519 ] Renato Garcia commented on JDO-751: --- I don't think Optional can reference null, it's either a value or "empty". > 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)
[jira] [Commented] (JDO-751) Support for Java8 Optional
[
https://issues.apache.org/jira/browse/JDO-751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15144601#comment-15144601
]
Tilmann Zäschke commented on JDO-751:
-
I completely agree, that defeats the purpose of {{Optional}} :-). My argument
is simply that unfortunately the way that Java implements it, you _can_ have a
{{null}} reference to an {{Optional}}. Of course JDOQL could implement
different semantics than Java by ignoring the case that a reference to an
{{Optional}} can be {{null}}, but it it would still be exactly that: different
semantics.
We can of course use different semantic in JDOQL and Java. But considering how
unlikely it is that a Field is of type {{Optional}} (after all it seems to be
discouraged by the Java people), I'm not sure that the potential benefits of a
shortcut are worth the potential future risk of deviating from Java.
Yes, comparing an {{Optional}} to {{null}} seems silly, but that doesn't mean
that nobody is going to do it or even find a clever use for it.
> 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)
[jira] [Commented] (JDO-751) Support for Java8 Optional
[ https://issues.apache.org/jira/browse/JDO-751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15144615#comment-15144615 ] Tilmann Zäschke commented on JDO-751: - ??How is this related to the "shortcuts" changing semantics, as in "shorcuts" meaning auto dereference of Optional fields? ?? I think it is related because auto-dereferencing means that you assume that the reference to the Optional cannot be null. ??I don't think Optional can reference null, it's either a value or "empty".?? So how would one check for "empty"? Would the only possibility be via "isPresent()"? ??In case we would like to make it not ambiguous in JDOQL how would this be implemented in a RDBMS for instance? ?? I don't know. But I'm not sure that the difficulty of implementing a feature in an RDBMS should guide the design of an API for object oriented persistence? > 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)
[jira] [Comment Edited] (JDO-751) Support for Java8 Optional
[ https://issues.apache.org/jira/browse/JDO-751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15144615#comment-15144615 ] Tilmann Zäschke edited comment on JDO-751 at 2/12/16 2:15 PM: -- ??How is this related to the "shortcuts" changing semantics, as in "shorcuts" meaning auto dereference of Optional fields??? I think it is related because auto-dereferencing means that you assume that the reference to the Optional cannot be null. ??I don't think Optional can reference null, it's either a value or "empty".?? So how would one check for "empty"? Would the only possibility be via "isPresent()"? ??In case we would like to make it not ambiguous in JDOQL how would this be implemented in a RDBMS for instance??? I don't know. But I'm not sure that the difficulty of implementing a feature in an RDBMS should guide the design of an API for object oriented persistence? was (Author: tilmann): ??How is this related to the "shortcuts" changing semantics, as in "shorcuts" meaning auto dereference of Optional fields? ?? I think it is related because auto-dereferencing means that you assume that the reference to the Optional cannot be null. ??I don't think Optional can reference null, it's either a value or "empty".?? So how would one check for "empty"? Would the only possibility be via "isPresent()"? ??In case we would like to make it not ambiguous in JDOQL how would this be implemented in a RDBMS for instance? ?? I don't know. But I'm not sure that the difficulty of implementing a feature in an RDBMS should guide the design of an API for object oriented persistence? > 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)
[jira] [Comment Edited] (JDO-751) Support for Java8 Optional
[ https://issues.apache.org/jira/browse/JDO-751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15144615#comment-15144615 ] Tilmann Zäschke edited comment on JDO-751 at 2/12/16 2:20 PM: -- ??How is this related to the "shortcuts" changing semantics, as in "shorcuts" meaning auto dereference of Optional fields??? I think it is related because auto-dereferencing means that you assume that the reference to the Optional cannot be null. ??I don't think Optional can reference null, it's either a value or "empty".?? So how would one check for "empty"? Would the only possibility be via "isPresent()"? ??In case we would like to make it not ambiguous in JDOQL how would this be implemented in a RDBMS for instance??? I don't know. But, at least ideally, I'm not sure that the difficulty of implementing a feature in an RDBMS should guide the design of an API for object oriented persistence? was (Author: tilmann): ??How is this related to the "shortcuts" changing semantics, as in "shorcuts" meaning auto dereference of Optional fields??? I think it is related because auto-dereferencing means that you assume that the reference to the Optional cannot be null. ??I don't think Optional can reference null, it's either a value or "empty".?? So how would one check for "empty"? Would the only possibility be via "isPresent()"? ??In case we would like to make it not ambiguous in JDOQL how would this be implemented in a RDBMS for instance??? I don't know. But I'm not sure that the difficulty of implementing a feature in an RDBMS should guide the design of an API for object oriented persistence? > 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)
Minutes: JDO TCK Conference Call Friday February 12, 9 AM Pacific Time (PST)
Attendees: Michael Bouschen, Craig Russell, Tilmann Zäschke On Feb 11, 2016, at 12:37 PM, Michael Bouschen wrote: Agenda: 1. JDO 3.1: Need to go through change lists in JIRA for 3.1 RC1 and 3.1 to prepare JCP Change Log 2. JDO social media properties (see email from Matthew) I’ll ask Matthew to send me the credentials and if anyone wants to manage any social property let me know. 3. JDO-751 "Support for Java8 Optional" https://issues.apache.org/jira/browse/JDO-751 Discussion continues in the JIRA. There are three models here. One is the domain object model. The second is the persistence model. The third is the JDOQL model that leans toward the domain model but has some shortcuts specifically addressing the issues also addressed by Optional (null handling). The big question is whether Optional should be part of the JDOQL model and/or the persistence model. 4. Any news on JDO-749 "Support for java.time types, and querying using associated methods" https://issues.apache.org/jira/browse/JDO-749? 5. Any news on JIRA JDO-747 "Behavior of delete() with multiple concurrent Transactions" https://issues.apache.org/jira/browse/JDO-747? Still waiting for the specification update before continuing with the patch. 6. Other issues Action Items from weeks past: [Oct 30 2015] AI Craig: File a maintenance review with JCP [May 15 2015] AI Craig Spec change for roll back an active transaction when closing a persistence manager (JDO-735) [Apr 17 2015] AI Craig: Oracle spec page on JDO need to be updated once the JCP Maintenance Release for JDO 3.1 is published [Oct 17 2014] AI Matthew any updates for "Modify specification to address NoSQL datastores": https://issues.apache.org/jira/browse/JDO-651? [Feb 28 2014] AI Everyone: take a look at https://issues.apache.org/jira/browse/JDO-712 [Feb 28 2014] AI Everyone: take a look at https://issues.apache.org/jira/browse/JDO-625 [Dec 13 2013] AI Craig file a JIRA for java.sql.Blob and java.sql.Clob as persistent field types [Aug 24 2012] AI Craig update the JIRAs JDO-689 JDO-690 and JDO-692 about JDOHelper methods. In process. Craig L Russell papa...@gmail.com
[jira] [Commented] (JDO-751) Support for Java8 Optional
[
https://issues.apache.org/jira/browse/JDO-751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15144996#comment-15144996
]
Tilmann Zäschke commented on JDO-751:
-
Just to repeat what was send at the end of the telecon: I favour the dual way
of allowing both {{postcode!=null}} and {{postcode.isPresent()}} in JDOQL. The
problem is that this can cause collision if the object referenced by the
{{Optional}} has the same method names as {{Optional}}. Currently, the only
problem occurs if the with {{Optional}} because {{List}} also has a get
method, although with a different signature.
The problem is that, if we allow {{Optional}} methods and at the same time
allow the short-cut with auto-dereferencing then we may get into trouble in
future. If we ever think about admitting method calls on domain objects, then
these could conflict with the methods of {{Optional}}. Similarily, we would be
in trouble if Java ever decides to add a {{isPresent()}} method to {{List}} or
{{Map}} (for whatever reason).
Fun question (not a likely use-case): How do we treat
{{Optional>}} where department is null? Should JDOQL do
double-auto-dereferencing?
> 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)
[jira] [Commented] (JDO-751) Support for Java8 Optional
[
https://issues.apache.org/jira/browse/JDO-751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15145027#comment-15145027
]
Tilmann Zäschke commented on JDO-751:
-
Maybe it should also be considered whether JDO may at some point want to add
something like lambdas do JDOQL. In that case, it would be useful to have the
{{isPresent()}}, {{orElse(...)}} and {{get()}} methods available.
> 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)
[jira] [Comment Edited] (JDO-751) Support for Java8 Optional
[
https://issues.apache.org/jira/browse/JDO-751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15145027#comment-15145027
]
Tilmann Zäschke edited comment on JDO-751 at 2/12/16 6:38 PM:
--
Maybe it should also be considered whether JDO may at some point want to add
something like lambdas / streams do JDOQL. In that case, it would be useful to
have the {{isPresent()}}, {{orElse(...)}} and {{get()}} methods available.
was (Author: tilmann):
Maybe it should also be considered whether JDO may at some point want to add
something like lambdas do JDOQL. In that case, it would be useful to have the
{{isPresent()}}, {{orElse(...)}} and {{get()}} methods available.
> 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)
[jira] [Commented] (JDO-751) Support for Java8 Optional
[
https://issues.apache.org/jira/browse/JDO-751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15145293#comment-15145293
]
Renato Garcia commented on JDO-751:
---
{quote}Fun question (not a likely use-case): How do we treat
Optional> where department is null? Should JDOQL do
double-auto-dereferencing?{quote}
Would it be a valid mapping to start with? Is {{List>}} valid?
> 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)
[jira] [Commented] (JDO-751) Support for Java8 Optional
[
https://issues.apache.org/jira/browse/JDO-751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15145294#comment-15145294
]
Renato Garcia commented on JDO-751:
---
{quote}I think it is related because auto-dereferencing means that you assume
that the reference to the Optional cannot be null.{quote}
Not necessarily, it depends on how you do it. It would be probably something
{{orElse(null)}} rather then {{get()}} to be compatible with JDOQL handling of
nulls.
{quote}So how would one check for "empty"? Would the only possibility be via
"isPresent()"?{quote}
In a query? Either comparing to "empty" using a variable or calling "isPresent"
if the method is implemented.
{quote}I don't know. But, at least ideally, I'm not sure that the difficulty of
implementing a feature in an RDBMS should guide the design of an API for object
oriented persistence?{quote}
Exercising the possible implementations is a good guidance of the practicality
of the API and helps understand the trade-offs imposed by the API.
> 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)
