[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=15155124#comment-15155124
]
Renato Garcia commented on JDO-751:
---
{quote}
MemberMetadata.getFieldType should return "Optional". I don't see the
problem with type erasure, since the metamodel uses strings to represent types.
{quote}
It would certainly work, but this would be inconsistent with containers i.e.
collections/maps/arrays, which are also parameterized types just like
Optional, thus creating a special case just to support Optional. In my
opinion this would be not justifiable when you could just use the existing
approach for containers.
> 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=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 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)
Re: Minutes: JDO TCK Conference Call Friday February 19, 9 AM Pacific Time (PST)
> > 2. News on JDO social media properties (see email from Matthew)? > > Message was sent to Matthew to send credentials to Craig. > > Greg Chase volunteered to help manage the Twitter account. Michael > volunteered for the Google+ account. And Craig volunteers for the Facebook > account. All the volunteers should get all of the credentials. Thanks to > Matthew for his service to date. > > For the other projects I help manage Twitter accounts, we follow Apache guidelines. Have the private@ account be the owner, and then manage access via Tweetdeck. That way we know precisely who is able to Tweet in the event that unfortunate activities occur. We've seen this in other project Twitter handles, and hence this is why its suggested to be set up this way. I'm not a member of the PMC, but if someone can facilitate password confirmations, I'm happy to tie the JDO twitter handle there, and I'm also happy to admin access to anyone else who wants to Tweet for JDO. -Greg
Minutes: JDO TCK Conference Call Friday February 19, 9 AM Pacific Time (PST)
Attendees: Michael Bouschen, Tilmann Zäschke, Craig Russell NOTE: Next week’s meeting will be two hours earlier: 7 AM PST 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 pending 2. News on JDO social media properties (see email from Matthew)? Message was sent to Matthew to send credentials to Craig. Greg Chase volunteered to help manage the Twitter account. Michael volunteered for the Google+ account. And Craig volunteers for the Facebook account. All the volunteers should get all of the credentials. Thanks to Matthew for his service to date. 3. JDO-751 "Support for Java8 Optional" https://issues.apache.org/jira/browse/JDO-751 What about use of variables that have type Optional? Perhaps we can treat them the same as parameters? What about support for Optional.orElse() so that JDOQL could use age.orElse(0) < 18. Persons without an age will be less than 18. Without support for orElse, the query would be more complicated. Tilmann volunteers to write the tck test. If a parameter is of type Optional can the user pass an instance of Employee or must the actual parameter be of type Optional? Regarding parameters of type domain object, the specification does not disallow them, but are there any test cases? The specification does not have an assertion near the special treatment of domain object identity comparison. AI Michael write a test case for domain objects as parameters. Include referencing fields and comparing to other domain objects by identity. Discussion continues on JIRA. 4. Any news on JIRA JDO-747 "Behavior of delete() with multiple concurrent Transactions" https://issues.apache.org/jira/browse/JDO-747? AI Craig: update specification for review 5. 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
Re: JDO social media accounts
Mr. Adams :) Craig - I manage @ApacheGeode, @Apache HAWQ, @ApacheMADlib for their PPMC's I'd be happy to tweet some love of JDO as well. We manage access through TweetDeck. If you guys are not set up for that, I'm happy to do that as well. Regards, -Greg Chase On Fri, Feb 19, 2016 at 8:52 AM, Craig Russell wrote: > Hi Matthew, > > We will be happy to take the social media accounts under our collective > wing. > > Can you send me a private message with the credentials? > > Anyone who wants to manage one or more accounts, please message the list > and I’ll forward the credentials. > > Craig > >
JDO social media accounts
Hi Matthew, We will be happy to take the social media accounts under our collective wing. Can you send me a private message with the credentials? Anyone who wants to manage one or more accounts, please message the list and I’ll forward the credentials. Craig
[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=15154475#comment-15154475 ] Craig L Russell commented on JDO-751: - I'd like to think how to accommodate object databases, where the user really wants to distinguish three cases in the datastore: Case 1. Null value Case 2. Empty value Case 3. Present value I think that a straight mapping that preserves the three cases is in alignment with the specification. How to distinguish them in JDOQL might be simple. Case 1. prop == null Case 2. !prop.isPresent() Case 3. prop.isPresent() Using the shorthand age == 7 would mean (age.isPresent() && age.get()==7) Is that good enough? > 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=15152861#comment-15152861
]
Craig L Russell edited comment on JDO-751 at 2/19/16 4:28 PM:
--
Here's another try at a solution.
Optional is a Java domain modeling concept that is loosely followed in JDOQL
to track the semantics but not necessarily the syntax.
Optional> is disallowed. If anyone can give a real example, I will
listen.
Mapping a persistent field of type Optional requires that the mapped
database field be nullable.
Add Optional as a JDOQL feature and allow methods get() and isPresent() to be
used with JDOQL. Consider adding .equals to this but only if we can't figure
out how to compare to null, other Optional, and primitive/boxed values.
To make it easier to express in JDOQL, assume a simple domain model with a
class Person with a field age of type Optional and field address of
type Optional. Address contains String city, String state, String
postalCode. The query is on class Person. The following are equivalent in JDOQL:
address!=null is equivalent to address.isPresent()
address.city=="New York" is equivalent to address.get().city=="New York"
address.city=="New York" is equivalent to (address.isPresent() &&
address.get().city=="New York")
address==null is equivalent to (!address.isPresent())
age==null is equivalent to !age.isPresent()
age==7 is equivalent to (age.isPresent() && age.get()==7)
If using the result feature of JDOQL, specifying the result to be address, the
type of the return value is Optional.
Parameters can be passed as type Optional.
setParameters("Optional paramOptInteger, Integer paramInteger, int
paramInt")
The following are equivalent in JDOQL:
age==paramInt is equivalent to (age.isPresent() && age.get()==paramInt)
age==paramInteger is equivalent to (age.isPresent() && age.get()==paramInteger)
{{age==paramOptInteger}} is equivalent to
(age.isPresent() && paramOptInteger.isPresent &&
age.get()==paramOptInteger.get()) ||
!age.isPresent()) && !(paramOptInteger.isPresent())
^^^ I think the above makes the case for auto-boxing parameters and fields
I did not see anything in the current specification that allows passing domain
objects as parameters, so it's unnecessary to discuss passing Optional
as parameters.
Other comments from discussion above:
I agree that there is a difference between null and empty, but it doesn't have
to matter. When we persist an object where the address field is null, we store
null in the datastore. If the address field is Optional.EMPTY, we store null in
the datastore. When we retrieve the object from the datastore, the Optional
will always be non-null.
MemberMetadata.getFieldType should return "Optional". I don't see the
problem with type erasure, since the metamodel uses strings to represent types.
was (Author: clr):
Here's another try at a solution.
Optional is a Java domain modeling concept that is loosely followed in JDOQL
to track the semantics but not necessarily the syntax.
Optional> is disallowed. If anyone can give a real example, I will
listen.
Mapping a persistent field of type Optional requires that the mapped
database field be nullable.
Add Optional as a JDOQL feature and allow methods get() and isPresent() to be
used with JDOQL. Consider adding .equals to this but only if we can't figure
out how to compare to null, other Optional, and primitive/boxed values.
To make it easier to express in JDOQL, assume a simple domain model with a
class Person with a field age of type Optional and field address of
type Optional. Address contains String city, String state, String
postalCode. The query is on class Person. The following are equivalent in JDOQL:
address!=null is equivalent to address.isPresent()
address.city=="New York" is equivalent to address.get().city=="New York"
address.city=="New York" is equivalent to (address.isPresent() &&
address.get().city=="New York")
address==null is equivalent to (!address.isPresent())
age==null is equivalent to !age.isPresent()
age==7 is equivalent to (age.isPresent() && age.get()==7)
age==7 is equivalent to (age.get()==7)
If using the result feature of JDOQL, specifying the result to be address, the
type of the return value is Optional.
Parameters can be passed as type Optional.
setParameters("Optional paramOptInteger, Integer paramInteger, int
paramInt")
The following are equivalent in JDOQL:
age==paramInt is equivalent to (age.isPresent() && age.get()==paramInt)
age==paramInteger is equivalent to (age.isPresent() && age.get()==paramInteger)
{{age==paramOptInteger}} is equivalent to
(age.isPresent() && paramOptInteger.isPresent &&
age.get()==paramOptInteger.get()) ||
!age.isPresent()) && !(paramOptInteger.isPresent())
^^^ I think the above makes the case for auto-boxing parameters and fields
I did not see anything in the current specification t
[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=15154457#comment-15154457 ] Craig L Russell commented on JDO-751: - Having begun to work with JavaScript over the last few years, I appreciate how they adapted the Java concept of null to the equality problem. If you have a property foo and another property bar, you can ask if foo == bar and you get true if both are null or both are not null and have the same "value". This is what I propose for JDOQL if both foo and bar are Optional. True, it's not strictly Java, but we already have made JDOQL just a bit friendlier than strict Java. > 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=15153660#comment-15153660
]
Renato Garcia edited comment on JDO-751 at 2/19/16 11:38 AM:
-
{quote}
I still don't get the difference between empty and null. Optional does have a
ofNullable() method, which can be used to set it to null. Otherwise, how do you
set it to be `empty`?
{quote}
You use Optional.empty(). Again, the idea of Optional is to abstract {{null}}
away. In the Optional world there are absolutely no nulls, and no {{null}}
references which would invalidate the whole concept as we talked before. Once
using Optional everything that is non-Optional is automatically assumed to be
non-nullable. You need to pick one approach and delimit this world well.
With this idea in mind, {{Optional.ofNullable()}} is for interoperability with
the non-Optional world because {{null}} is still out there. Also, note that you
are not "setting" {{null}}, because Optional is immutable, so you get back a
reference that represents empty. Equally you don't obtain {{null}} from an
Optional - you have to explicitly convert it back to {{null}}, which you'd only
do when you need to go back to non-Optional world. {{Optional.get}} will never
give you back a {{null}}, it raises an {{NoSuchElementException}}, therefore
the code below will always throw an exception:
{{Optional.ofNullable(null).get() == null}}
So you'd need to do something like:
{code}
Optional fooOpt = Optional.ofNullable(null);
boolean expr = (fooOpt.isPresent() ? fooOpt.get() : null) == null;
{code}
or
{{Optional.ofNullable(null).orElse(null) == null}}
was (Author: rgarcia):
{quote}
I still don't get the difference between empty and null. Optional does have a
ofNullable() method, which can be used to set it to null. Otherwise, how do you
set it to be `empty`?
{quote}
You use Optional.empty(). Again, the idea of Optional is to abstract {{null}}
away. In the Optional world there are absolutely no nulls, and no {{null}}
references which would invalidate the whole concept as we talked before. Once
using Optional everything that is non-Optional is automatically assumed to be
non-nullable. You need to pick one approach and delimit this world well.
With this idea in mind, {{Optional.ofNullable()}} is for interoperability with
the non-Optional world because {{null}} is still out there. Also, note that you
are not "setting" {{null}}, because Optional is immutable, so you get back a
reference that represents empty. Equally you don't obtain {{null}} from an
Optional - you have to explicitly convert it back to {{null}}, which you'd only
do when you need to go back to non-Optional world. {{Optional.get}} will never
give you back a {{null}}, it raises an {{NoSuchElementException}}, therefore
the code below will always throw an exception:
{{Optional.ofNullable(null).get() == null}}
So you'd need to do something like:
{{
Optional fooOpt = Optional.ofNullable(null);
boolean expr = (fooOpt.isPresent() ? fooOpt.get() : null) == null;
}}
or
{{Optional.ofNullable(null).orElse(null) == 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)
[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=15153925#comment-15153925
]
Tilmann Zäschke commented on JDO-751:
-
{quote}
{{Optional.get}} will never give you back a {{null}}, it raises an
{{NoSuchElementException}}
{quote}
Ah, I hadn't realized that, that explains some things.
{quote}
Once using Optional everything that is non-Optional is automatically assumed to
be non-nullable. You need to pick one approach and delimit this world well.
{quote}
I'm with you here, my concern was only that people are free to use {{null}}
outside {{Optional}}, and I think we need to make sure that we cover this (i.e.
think about it, not necessarily allow it), because it's perfectly valid Java,
even if it is not obviously sensible or what they 'should' do.
> 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)
