[jira] [Comment Edited] (JDO-751) Support for Java8 Optional

[Craig L Russell (JIRA)]

[ 
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 AM:
--

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() && paramOptInt.isPresent 
&& 

age.get()==paramOptInteger)|((!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() && paramOptInt.isPresent 
&& 

age.get()==paramOptInteger)||((!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 s

[jira] [Comment Edited] (JDO-751) Support for Java8 Optional

[Craig L Russell (JIRA)]

[ 
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:33 AM:
--

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() && 
paramOptInt.isPresent && }}
  {{  age.get()==paramOptInteger)| ( ( 
!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() && paramOptInt.isPresent 
&& 
age.get()==paramOptInteger)| ( ( 
!age.isPresent())&&!(paramOptInteger.isPresent())
^^^ I think the above makes the case for auto-boxing parameters and fields

I did not see anythi

[jira] [Comment Edited] (JDO-751) Support for Java8 Optional

[Craig L Russell (JIRA)]

[ 
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:34 AM:
--

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() && paramOptInt.isPresent && }}
{{  age.get()==paramOptInteger)| ( ( 
!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() && 
paramOptInt.isPresent && }}
  {{  age.get()==paramOptInteger)| ( ( 
!age.isPresent())&&!(paramOptInteger.isPresent())}}
^^^ I think the above makes the case for auto-boxing parameters and fields

I did no

[jira] [Comment Edited] (JDO-751) Support for Java8 Optional

[Craig L Russell (JIRA)]

[ 
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:38 AM:
--

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 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() && paramOptInt.isPresent && age.get()==paramOptInteger) || 
}}
{{!age.isPresent()) && !(paramOptInteger.isPresent()) }}
^^^ I think the above makes the case for auto-boxing parameters and fields

I did not see

[jira] [Comment Edited] (JDO-751) Support for Java8 Optional

[Craig L Russell (JIRA)]

[ 
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:30 AM:
--

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() && paramOptInt.isPresent 
&& 
age.get()==paramOptInteger)| ( ( 
!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() && paramOptInt.isPresent 
&& 
age.get()==paramOptInteger)| ( ( 
!age.isPresent()))&&!(paramOptInteger.isPresent())
^^^ I think the above makes the case for auto-boxing parameters and fields

I did not see anything in the c

[jira] [Comment Edited] (JDO-751) Support for Java8 Optional

[Craig L Russell (JIRA)]

[ 
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:36 AM:
--

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() && paramOptInt.isPresent && age.get()==paramOptInteger) || 
}}
{{!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() && paramOptInt.isPresent && }}
{{  age.get()==paramOptInteger)| ( ( 
!age.isPresent())&&!(paramOptInteger.isPresent())}}
^^^ I think the above makes the case for auto-boxing parameters and fields

I did not s

[jira] [Comment Edited] (JDO-751) Support for Java8 Optional

[Craig L Russell (JIRA)]

[ 
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:31 AM:
--

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() && paramOptInt.isPresent 
&& 
age.get()==paramOptInteger)| ( ( 
!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() && paramOptInt.isPresent 
&& 
age.get()==paramOptInteger)| ( ( 
!age.isPresent())&&!(paramOptInteger.isPresent())
^^^ I think the above makes the case for auto-boxing parameters and fields

I did not see anything in 

[jira] [Comment Edited] (JDO-751) Support for Java8 Optional

[Craig L Russell (JIRA)]

[ 
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:31 AM:
--

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() && paramOptInt.isPresent 
&& 
age.get()==paramOptInteger)| ( ( 
!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() && paramOptInt.isPresent 
&& 
age.get()==paramOptInteger)| ( ( 
!age.isPresent())&&!(paramOptInteger.isPresent())
^^^ I think the above makes the case for auto-boxing parameters and fields

I did not see anything in the 

[jira] [Comment Edited] (JDO-751) Support for Java8 Optional

[Craig L Russell (JIRA)]

[ 
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:34 AM:
--

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() && 
paramOptInt.isPresent && }}
  {{  age.get()==paramOptInteger)| ( ( 
!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() && 
paramOptInt.isPresent && }}
  {{  age.get()==paramOptInteger)| ( ( 
!age.isPresent())&&!(paramOptInteger.isPresent())}}
^^^ I think the above makes the case for auto-boxing parameters and fields

I did not s

[jira] [Comment Edited] (JDO-751) Support for Java8 Optional

[Craig L Russell (JIRA)]

[ 
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:29 AM:
--

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() && paramOptInt.isPresent 
&& 
age.get()==paramOptInteger)| ( ( 
!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() && paramOptInt.isPresent 
&& 

age.get()==paramOptInteger)|((!age.isPresent()))&&!(paramOptInteger.isPresent())
^^^ I think the above makes the case for auto-boxing parameters and fields

I did not see anything in the cur

[jira] [Comment Edited] (JDO-751) Support for Java8 Optional

[Craig L Russell (JIRA)]

[ 
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:32 AM:
--

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() && paramOptInt.isPresent 
&& 
age.get()==paramOptInteger)| ( ( 
!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() && paramOptInt.isPresent 
&& 
age.get()==paramOptInteger)| ( ( 
!age.isPresent())&&!(paramOptInteger.isPresent())
^^^ I think the above makes the case for auto-boxing parameters and fields

I did not see anything i

[jira] [Commented] (JDO-751) Support for Java8 Optional

[Renato Garcia (JIRA)]

[ 
https://issues.apache.org/jira/browse/JDO-751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15153660#comment-15153660
 ] 

Renato Garcia commented on JDO-751:
---

{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] [Comment Edited] (JDO-751) Support for Java8 Optional

[Craig L Russell (JIRA)]

[ 
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/18/16 8:56 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)
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() && paramOptInt.isPresent 
&& 

age.get()==paramOptInteger)||((!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() && paramOptInt.isPresent 
&& 

age.get()==paramOptInteger)||((!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 speci

JDO TCK Conference Call Friday February 19, 9 AM Pacific Time (PST)

[Michael Bouschen]

Hi,

We will have our regular meeting Friday, February 19 at 9 AM Pacific Time (PST) 
to discuss JDO TCK issues and status. 

We will try the new dial-in for audio and video. You need a Skype account to 
join.
https://join.skype.com/RUHyGMHxNDyR 

Please let us know if you do not have a Skype account and want to join the 
call. 
Then we can switch back to Google Hangouts: http://goo.gl/sCKJaS

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. News on JDO social media properties (see email from Matthew)?
3. JDO-751 "Support for Java8 Optional" 
https://issues.apache.org/jira/browse/JDO-751
4. Any news on JIRA JDO-747 "Behavior of delete() with multiple concurrent 
Transactions" https://issues.apache.org/jira/browse/JDO-747?
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.

Regards Michael 

-- 
*Michael Bouschen*
*Prokurist*

akquinet tech@spree GmbH
Bülowstr. 66, D-10783 Berlin

Fon:   +49 30 235 520-33
Fax:   +49 30 217 520-12
Email: michael.bousc...@akquinet.de
Web:   www.akquinet.de 

akquinet tech@spree GmbH, Berlin
Geschäftsführung: Martin Weber, Dr. Torsten Fink
Amtsgericht Berlin-Charlottenburg HRB 86780 B
USt.-Id. Nr.: DE 225 964 680

[jira] [Commented] (JDO-751) Support for Java8 Optional

[Craig L Russell (JIRA)]

[ 
https://issues.apache.org/jira/browse/JDO-751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15152861#comment-15152861
 ] 

Craig L Russell commented on JDO-751:
-

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() && paramOptInt.isPresent 
&& 

age.get()==paramOptInteger)||((!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.



> 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

[JIRA]

[ 
https://issues.apache.org/jira/browse/JDO-751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15152165#comment-15152165
 ] 

Tilmann Zäschke edited comment on JDO-751 at 2/18/16 12:09 PM:
---

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`?

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.

As to whether {{List>}} is valid, I think it is. We could disallow 
{{Optional>}} but that would mean deviating even further from the 
Java object model.

@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?

I will try to summarize a bit, basically it is `follow the way {{Optional}} is 
implemented in Java` vs `follow the idea of {{Optional}}, as available in other 
languages`:

1. We could strictly follow the Java object model and only access {{Optional}} 
via {{get()}} and so on.
Advantages: I think this would be least error prone and easiest for the user. 
Also, the semantics would be clean (same a Java). Also: probably easier to 
implement in an ODBMS.
Disadvantages: This goes against the spirit of {{Optional}} (However it follows 
the implementation of Optional). Also, there seem to be difficulties with 
implementing this in an RDBMS.

2. We introduce auto-dereferencing and assume that a reference to an optional 
cannot be null.
Advantages: less typing for users. Also, may be easier to implement in RDBMS.
Disadvantage: Deviation from the OO-model may (slightly) confuse users and may 
make implementation in ODBMS harder. Also, there are still open questions: 
a) What to do with the meta-data info (see Renato's post)
b) How to compare with null/empty? We could introduce an {{empty}} keyword in 
JDOQL for comparison with {{Optional}} fields.
c) What happens if a persistent class has an field {{Optional<...>}} that is 
{{null}}? Answered by Craig: return {{false}} for match.
d) Should we could disallow {{== null}}? But how do we prevent comparison to a 
parameter of type {{Optional}} that is {{null}} or another field of type 
{{Optional}} that is {{null}}?
e) What about the {{Optional>}} case, should they all be 
auto-dereferenced? What if either of them is empty? Can we query for the first 
being empty vs the second being empty? Answered by Craig: Can be disallowed.
f) By Renato: Return type of query: {{Optional}} vs {{T}}

Anything I missed? I think we more or less agreed on option 2) in the last 
telecon, but I thought I list both options here because there still seem to be 
some open issues.


was (Author: tilmann):
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`?

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.

As to whether {{List>}} is valid, I think it is. We could disallow 
{{Optional>}} but that would mean deviating even further from the 
Java object model.

@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?

I will try to summarize a bit, basically it is `follow the way {{Optional}} is 
implemented in Java` vs `follow the idea of {{Optional}}, as available in other 
languages`:

1. We could strictly follow the Java object model and only access {{Optional}} 
via {{get()}} and so on.
Advantages: I think this woul

[jira] [Issue Comment Deleted] (JDO-751) Support for Java8 Optional

[JIRA]

 [ 
https://issues.apache.org/jira/browse/JDO-751?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Tilmann Zäschke updated JDO-751:

Comment: was deleted

(was: @Craig
Sorry, I think overlooked your post.
You raised an excellent point about JDOQL that return {{false}} if one in 
{{person.address.postcode}} is {{null}}. 

So this would for example answer point e) (we disallow Optional>), 
and c) (return {{false}}).
I think it leaves points a) metadata (Renato's point), and  b)/d) about 
comparison to {{null}}/{{empty}}. Disallowing comparison to {{null}} could have 
quite some impact I suppose...
)

> 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

[JIRA]

[ 
https://issues.apache.org/jira/browse/JDO-751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15152165#comment-15152165
 ] 

Tilmann Zäschke edited comment on JDO-751 at 2/18/16 11:49 AM:
---

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`?

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.

As to whether {{List>}} is valid, I think it is. We could disallow 
{{Optional>}} but that would mean deviating even further from the 
Java object model.

@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?

I will try to summarize a bit, basically it is `follow the way {{Optional}} is 
implemented in Java` vs `follow the idea of {{Optional}}, as available in other 
languages`:

1. We could strictly follow the Java object model and only access {{Optional}} 
via {{get()}} and so on.
Advantages: I think this would be least error prone and easiest for the user. 
Also, the semantics would be clean (same a Java). Also: probably easier to 
implement in an ODBMS.
Disadvantages: This goes against the spirit of {{Optional}} (However it follows 
the implementation of Optional). Also, there seem to be difficulties with 
implementing this in an RDBMS.

2. We introduce auto-dereferencing and assume that a reference to an optional 
cannot be null.
Advantages: less typing for users. Also, may be easier to implement in RDBMS.
Disadvantage: Deviation from the OO-model may (slightly) confuse users and may 
make implementation in ODBMS harder. Also, there are still open questions: 
a) What to do with the meta-data info (see Renato's post)
b) How to compare with null/empty? We could introduce an {{empty}} keyword in 
JDOQL for comparison with {{Optional}} fields.
c) What happens if a persistent class has an field {{Optional<...>}} that is 
{{null}}? Answered by Craig: return {{false}} for match.
d) Should we could disallow {{== null}}? But how do we prevent comparison to a 
parameter of type {{Optional}} that is {{null}} or another field of type 
{{Optional}} that is {{null}}?
e) What about the {{Optional>}} case, should they all be 
auto-dereferenced? What if either of them is empty? Can we query for the first 
being empty vs the second being empty? Answered by Craig: Can be disallowed.
f) By Renato: Return type of query: {{Optional}} vs {{T}}


was (Author: tilmann):
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`?

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.

As to whether {{List>}} is valid, I think it is. We could disallow 
{{Optional>}} but that would mean deviating even further from the 
Java object model.

@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?

I will try to summarize a bit, basically it is `follow the way {{Optional}} is 
implemented in Java` vs `follow the idea of {{Optional}}, as available in other 
languages`:

1. We could strictly follow the Java object model and only access {{Optional}} 
via {{get()}} and so on.
Advantages: I think this would be least error prone and easiest for the user. 
Also, the semantics would be clean (same a Java). Also: probably easier to 
implement in an ODBMS.
Disadvantages: This goes a

[jira] [Comment Edited] (JDO-751) Support for Java8 Optional

[JIRA]

[ 
https://issues.apache.org/jira/browse/JDO-751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15152197#comment-15152197
 ] 

Tilmann Zäschke edited comment on JDO-751 at 2/18/16 11:45 AM:
---

@Craig
Sorry, I think overlooked your post.
You raised an excellent point about JDOQL that return {{false}} if one in 
{{person.address.postcode}} is {{null}}. 

So this would for example answer point e) (we disallow Optional>), 
and c) (return {{false}}).
I think it leaves points a) metadata (Renato's point), and  b)/d) about 
comparison to {{null}}/{{empty}}. Disallowing comparison to {{null}} could have 
quite some impact I suppose...



was (Author: tilmann):
@Craig
Sorry, I think overlooked your post.
You raised an excellent point about JDOQL that return {{false}} if one in 
{{person.address.postcode}} is {{null}}. But that means I can still compare to 

So this would for example answer point e) (we disallow Optional>), 
and c) (return {{false}}).
I think it leaves points a) metadata (Renato's point), and  b)/d) about 
comparison to {{null}}/{{empty}}. Disallowing comparison to {{null}} could have 
quite some impact I suppose...


> 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

[JIRA]

[ 
https://issues.apache.org/jira/browse/JDO-751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15152197#comment-15152197
 ] 

Tilmann Zäschke commented on JDO-751:
-

@Craig
Sorry, I think overlooked your post.
You raised an excellent point about JDOQL that return {{false}} if one in 
{{person.address.postcode}} is {{null}}. But that means I can still compare to 

So this would for example answer point e) (we disallow Optional>), 
and c) (return {{false}}).
I think it leaves points a) metadata (Renato's point), and  b)/d) about 
comparison to {{null}}/{{empty}}. Disallowing comparison to {{null}} could have 
quite some impact I suppose...


> 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

[JIRA]

[ 
https://issues.apache.org/jira/browse/JDO-751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15152165#comment-15152165
 ] 

Tilmann Zäschke edited comment on JDO-751 at 2/18/16 11:19 AM:
---

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`?

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.

As to whether {{List>}} is valid, I think it is. We could disallow 
{{Optional>}} but that would mean deviating even further from the 
Java object model.

@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?

I will try to summarize a bit, basically it is `follow the way {{Optional}} is 
implemented in Java` vs `follow the idea of {{Optional}}, as available in other 
languages`:

1. We could strictly follow the Java object model and only access {{Optional}} 
via {{get()}} and so on.
Advantages: I think this would be least error prone and easiest for the user. 
Also, the semantics would be clean (same a Java). Also: probably easier to 
implement in an ODBMS.
Disadvantages: This goes against the spirit of {{Optional}} (However it follows 
the implementation of Optional). Also, there seem to be difficulties with 
implementing this in an RDBMS.

2. We introduce auto-dereferencing and assume that a reference to an optional 
cannot be null.
Advantages: less typing for users. Also, may be easier to implement in RDBMS.
Disadvantage: Deviation from the OO-model may (slightly) confuse users and may 
make implementation in ODBMS harder. Also, there are still open questions: 
a) What to do with the meta-data info (see Renato's post)
b) How to compare with null/empty? We could introduce an {{empty}} keyword in 
JDOQL for comparison with {{Optional}} fields.
c) What happens if a persistent class has an field {{Optional<...>}} that is 
{{null}}?
d) Should we could disallow {{== null}}? But how do we prevent comparison to a 
parameter of type {{Optional}} that is {{null}} or another field of type 
{{Optional}} that is {{null}}?
e) What about the {{Optional>}} case, should they all be 
auto-dereferenced? What if either of them is empty? Can we query for the first 
being empty vs the second being empty?


was (Author: tilmann):
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`?

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.

As to whether {{List>}} is valid, I think it is. We could disallow 
{{Optional>}} but that would mean deviating even further from the 
Java object model.

@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?

I will try to summarize a bit, basically it is `follow the way {{Optional}} is 
implemented in Java` vs `follow the idea of {{Optional}}, as available in other 
languages`:

1. We could strictly follow the Java object model and only access 'Optional' 
via 'get()' and so on.
Advantages: I think this would be least error prone and easiest for the user. 
Also, the semantics would be clean (same a Java). Also: probably easier to 
implement in an ODBMS.
Disadvantages: This goes against the spirit of {{Optional}} (However it follows 
the implementation of Optional). Also, there seem to be difficulties with 
implementing this

[jira] [Commented] (JDO-751) Support for Java8 Optional

[JIRA]

[ 
https://issues.apache.org/jira/browse/JDO-751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15152165#comment-15152165
 ] 

Tilmann Zäschke commented on JDO-751:
-

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`?

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.

As to whether {{List>}} is valid, I think it is. We could disallow 
{{Optional>}} but that would mean deviating even further from the 
Java object model.

@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?

I will try to summarize a bit, basically it is `follow the way {{Optional}} is 
implemented in Java` vs `follow the idea of {{Optional}}, as available in other 
languages`:

1. We could strictly follow the Java object model and only access 'Optional' 
via 'get()' and so on.
Advantages: I think this would be least error prone and easiest for the user. 
Also, the semantics would be clean (same a Java). Also: probably easier to 
implement in an ODBMS.
Disadvantages: This goes against the spirit of {{Optional}} (However it follows 
the implementation of Optional). Also, there seem to be difficulties with 
implementing this in an RDBMS.

2. We introduce auto-dereferencing and assume that a reference to an optional 
cannot be null.
Advantages: less typing fo users. Also, may be easier to implement in RDBMS.
Disadvantage: Deviation from the OO-model may (slightly) confuse users and may 
make implementation in ODBMS harder. Also, there are still open questions: 
a) What to do with the meta-data info (see Renato's post)
b) How to compare with null/empty? We could introduce an 'empty' keyword in 
JDOQL for comparison with 'Optional' fields.
c) What happens if a persistent class has an field 'Optional<...>' that is null?
d) Should we could disallow '== null'? But how do we prevent comparison to a 
parameter of type {{Optional}} that is 'null' or another field of type 
{{Optional}} that is {{null}}?
e) What about the {{Optional>}} case, should they all be 
auto-dereferenced? What if either of them is empty? Can we query for the first 
being empty vs the second being 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)