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

2016-07-08 Thread Craig L Russell (JIRA)

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

Craig L Russell commented on JDO-751:
-

I'm still not convinced that optionalPC.orElse(anything) has value anywhere 
except in the SELECT clause. 

> 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
> Fix For: JDO 3.2
>
> Attachments: JDO-751-tck-patch-v5.txt
>
>
> 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

2016-07-08 Thread Craig L Russell (JIRA)

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

Craig L Russell commented on JDO-751:
-

Starting to work on the specification:

Persistent Object Model 6.4.3

java.lang.Optional

JDO implementations must support fields of type Optional where T is any 
supported Object type. They may be mapped to nullable datastore types or to 
Optional types at the option of the JDO implementation.



> 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
> Fix For: JDO 3.2
>
> Attachments: JDO-751-tck-patch-v5.txt
>
>
> 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

2016-06-23 Thread Andy Jefferson (JIRA)

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

Andy Jefferson commented on JDO-751:


1. I said DN equates a transient to null (nothing else reasonable to put it as 
IMHO - the log has a message about it). This is fine when comparing null with 
persistent (the other test), since it doesn't equate. In your test it is not 
fine for the reason I mentioned.

> 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
> Fix For: JDO 3.2
>
> Attachments: JDO-751-tck-patch-v4.txt
>
>
> 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

2016-06-23 Thread JIRA

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

Tilmann Zäschke commented on JDO-751:
-

1. About not being able to handle transient PCs, what about the 
{{org.apache.jdo.tck.query.jdoql.ComparingPersistentAndNonPersistentInstance}} 
test? In this test DN seems to accept a transient PC param, at least to confirm 
that it evaluates to false. 

> 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
> Fix For: JDO 3.2
>
> Attachments: JDO-751-tck-patch-v4.txt
>
>
> 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

2016-06-19 Thread JIRA

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

Tilmann Zäschke commented on JDO-751:
-

Thanks for the feedback.
1. Yes, you are right, and I do not expect the passed in persistent object to 
be equal to any database object. It is only compared to itself (which should 
return 'equal') and to 'null' (which should return 'not equal')
2. Okay, but I would expect the query engine of an DBMS to take care of that 
and apply the same 'truncation' to query parameters as it applies to stored 
values. So in the worst case it should return additional results that have a 
very similar timestamp, or not? The two dates that I use are over 15 minutes 
apart, so I wouldn't expect a problem here. I can adjust this if this turns out 
to be a problem.
3. Hmm, I think if {{ref.ref.id}} is common and use of Optional becomes common, 
then {{optional.optional.id}} may also become common ... . As simple example 
would be a family database where I want to find all grandchildren of a person 
via {{father.father.id == 33}} (and 3 similar queries).

A separate question (discussed in the meeting) is whether we really want to 
have {{orElse}} in WHERE clauses, or whether we should limit it to SELECT 
clause. For SELECT clauses we at least have a good use case (provided by Andy), 
for WHERE we don't really have that yet.

> 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
> Fix For: JDO 3.2
>
> Attachments: JDO-751-tck-patch-v4.txt
>
>
> 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

2016-06-18 Thread Andy Jefferson (JIRA)

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

Andy Jefferson commented on JDO-751:


Comments from cursory scan of the patch
1. You use a transient PC object passed in to a query. As per JDO spec 
assertion 14.6.2-44 "Comparisons between persistent and non-persistent 
instances return not equal". Do not use a transient PC object (which has no 
"id" as such), use detached or persistent-clean if you want to judge equality.
2. Using date equality is error prone since some datastores (RDBMS) don't store 
the precise millisecs so any comparison may work or may not depending on the 
precise nature of JDBC driver, and RDBMS handling.
3. Using optional.optional.xxx is getting some way from what I would 
term "common use-case"

> 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
> Fix For: JDO 3.2
>
> Attachments: JDO-751-tck-patch-v4.txt
>
>
> 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

2016-06-04 Thread JIRA

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

Tilmann Zäschke commented on JDO-751:
-

As mentioned in the telecon, I found that the query {{"!(optionalPC != null)"}} 
(where optionalPC is a field of type {{Optional}}) causes an SQL error: 

{{java.sql.SQLSyntaxErrorException: Syntax error: Encountered "NOT" at line 1, 
column 185.}}

The generated query looks as follows:

{{SELECT 'org.apache.jdo.tck.pc.query.OptionalSample' AS 
NUCLEUS_TYPE,A0.ID,A0.OPTIONAL_DATE,A0.OPTIONAL_INTEGER,A0.OPTIONAL_STRING FROM 
APPLICATIONIDENTITY0.OPTIONALSAMPLE A0 WHERE NOT NOT (A0.OPTIONAL_PC IS NULL)}}

This is presumably due to the {{NOT NOT}} near the end.


> 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
> Fix For: JDO 3.2
>
> Attachments: JDO-751-tck-patch-v2.txt
>
>
> 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

2016-04-17 Thread JIRA

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

Tilmann Zäschke commented on JDO-751:
-

Interesting. I had tried it with variables, but they only gave me the basic  
or  type. It didn't expect that fields behave differently and give you the 
actual generic type, but it appears they do. 
Still, we can only catch it if the generic type is actually given and precise 
enough (not {{}} or {{}} or omitted). 

> 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
> Fix For: JDO 3.2
>
>
> 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

2016-04-15 Thread Craig L Russell (JIRA)

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

Craig L Russell commented on JDO-751:
-

Just looked again at the class file metadata available at enhancement time. 
Using field.getGenericType() you can get the generic type of the field. So we 
probably can disallow this case if we choose. That's my vote.

> 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
> Fix For: JDO 3.2
>
>
> 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

2016-04-15 Thread Craig L Russell (JIRA)

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

Craig L Russell commented on JDO-751:
-

Tilmann: It might make more sense simply to say that the behavior of 
Optional is not defined. We cannot reliably detect this case.

> 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
> Fix For: JDO 3.2
>
>
> 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

2016-04-04 Thread JIRA

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

Tilmann Zäschke commented on JDO-751:
-

I just realise that throwing an exception during enhancement probably won't be 
possible, because after type erasure, the field will simply be of type 
{{Optional}}. Chained {{Optional}} can only be detected during 
serilization.

Should we throw the Exception during serialization?

> 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

2016-04-01 Thread Craig L Russell (JIRA)

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

Craig L Russell commented on JDO-751:
-

Regarding Optional

I think we should throw StupidUserException when trying to enhance a class with 
a property of type Optional

If some user later has a real use case we can look at it then.

> 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

2016-02-27 Thread JIRA

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

Tilmann Zäschke commented on JDO-751:
-

The argument or supporting {{orElse()}} would be that these are probably the 3 
basic {{Optional}} operations and that it would complement JDOQL's other 
conditional statement:{{if}}  (I though there was {{x==y?a:b}} as well, but I 
can't find it now). But we should only add features that will actually be used, 
do we have any information how much that is used?


> 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

2016-02-19 Thread Renato Garcia (JIRA)

[ 
https://issues.apache.org/jira/browse/JDO-751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

2016-02-19 Thread Renato Garcia (JIRA)

[ 
https://issues.apache.org/jira/browse/JDO-751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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)


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

2016-02-19 Thread Craig L Russell (JIRA)

[ 
https://issues.apache.org/jira/browse/JDO-751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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] [Commented] (JDO-751) Support for Java8 Optional

2016-02-19 Thread Craig L Russell (JIRA)

[ 
https://issues.apache.org/jira/browse/JDO-751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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] [Commented] (JDO-751) Support for Java8 Optional

2016-02-19 Thread JIRA

[ 
https://issues.apache.org/jira/browse/JDO-751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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)


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

2016-02-18 Thread Renato Garcia (JIRA)

[ 
https://issues.apache.org/jira/browse/JDO-751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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] [Commented] (JDO-751) Support for Java8 Optional

2016-02-18 Thread Craig L Russell (JIRA)

[ 
https://issues.apache.org/jira/browse/JDO-751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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] [Commented] (JDO-751) Support for Java8 Optional

2016-02-18 Thread JIRA

[ 
https://issues.apache.org/jira/browse/JDO-751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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] [Commented] (JDO-751) Support for Java8 Optional

2016-02-18 Thread JIRA

[ 
https://issues.apache.org/jira/browse/JDO-751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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)


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

2016-02-13 Thread Renato Garcia (JIRA)

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

Renato Garcia commented on JDO-751:
---

What about the type of the returned field in the JDOQL result clause 
{{person.address}}? Optional or T?

> 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

2016-02-13 Thread Renato Garcia (JIRA)

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

Renato Garcia commented on JDO-751:
---

[~apacheb...@tkuhn.de]
I've edited to my comment to clarify what I meant about using "null" as a 
parameter and expect "empty" results.

> 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

2016-02-13 Thread Craig L Russell (JIRA)

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

Craig L Russell commented on JDO-751:
-

I'd suggest we consider a field of type Optional to be of type T in the 
JDOQL and persistence domains. This is quite similar to some automatic behavior 
in Java where a field of type Integer is auto-(un)boxed where an int is 
required. Even though the semantics of non-null database fields are identical 
to int, and null database fields are identical to Integer, we allow mapping 
either way. In JDOQL we don't require explicit checking for null-valued fields. 
Dereferencing a null-valued database field results in disqualifying the JDOQL 
clause, not throwing an exception.

The example in JDOQL person.address.postCode == foo is instructive. The 
persistent field address is declared as Optional. For the purposes of 
this discussion, it doesn't matter whether Address is mapped as first class or 
second class. 

If we use strict Java semantics in JDOQL, we have (person.address.isPresent() 
&& person.address.get().postCode == "2BRN2B"). Very similar to what we rejected 
in JDOQL to handle nulls: (person.address!=null && person.address.postCode == 
"2BRN2B"). 

Usability is the reason we rejected this and opted for the simpler 
person.address.postCode == "2BRN2B". 

Do we plan to add streams/lambdas to JDOQL? How about executing user-defined 
(domain) methods in the datastore? I think that there will be many more issues 
than Optional if/when we get to these features. 

@Tilmann: How do we treat Optional where department is 
null? Should JDOQL do double-auto-dereferencing? 

I would disallow Optional. 

@Renato: What would be the type of the parameter for a variable in a query? 
From what I understand it would be T to be consistent with accepting null?

Yes, the parameter would be of type T for parameters. The parameter could be 
null or non-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

2016-02-12 Thread Renato Garcia (JIRA)

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

Renato Garcia commented on JDO-751:
---

What would be the type of the parameter for a variable in a query? From what I 
understand it would be T to be consistent with accepting null?

Wouldn't it still be dereferencing Optional instead of nulls, given that the 
actual type of the field is Optional and the JDOQL reflects the Java model 
and not the datastore model?

In general Optional like classes (scala.Option, guava's Optional) are an 
alternative approach to represent nullability, where you don't use {{null}} in 
your code, so ideally this should be extended to the query and not force people 
to use {{null}} for querying. They are not interchangeable and you shouldn't 
mix them - You either use one or the other. Therefore, querying with {{null}} 
when using Optional is conceptually wrong, and I guess making this the 
recommended/official way just seems odd... What about datastores that can store 
Optional and keep it's empty/null distinction? I believe that how it is mapped 
to the datastore should be an implementation detail.

If there will be no support for methods (although I think that methods would 
make the query more expressive), then just using variables would suffice by 
passing an {{Option.empty()}} as parameter to query for "empty" and {{ 
Optional.of(value) }} for value, so no special cases.

> Support for Java8 Optional
> --
>
> Key: JDO-751
> URL: https://issues.apache.org/jira/browse/JDO-751
> Project: JDO
>  Issue Type: New Feature
>  Components: specification, tck
>Reporter: Andy Jefferson
>
> java.util.Optional provides a feature that is available in other languages. 
> Since JDO 3.2 will be for Java8+ then it makes sense to add support for this 
> as a "supported persistable type"



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


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

2016-02-12 Thread Renato Garcia (JIRA)

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

Renato Garcia commented on JDO-751:
---

Regarding "shortcuts", I don't see why they change semantics? Aren't they just 
syntax sugar? I do think that more thought should be put into it though.

> Support for Java8 Optional
> --
>
> Key: JDO-751
> URL: https://issues.apache.org/jira/browse/JDO-751
> Project: JDO
>  Issue Type: New Feature
>  Components: specification, tck
>Reporter: Andy Jefferson
>
> java.util.Optional provides a feature that is available in other languages. 
> Since JDO 3.2 will be for Java8+ then it makes sense to add support for this 
> as a "supported persistable type"



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


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

2016-02-12 Thread Renato Garcia (JIRA)

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

Renato Garcia commented on JDO-751:
---

I don't think Optional can reference null, it's either a value or "empty".

> Support for Java8 Optional
> --
>
> Key: JDO-751
> URL: https://issues.apache.org/jira/browse/JDO-751
> Project: JDO
>  Issue Type: New Feature
>  Components: specification, tck
>Reporter: Andy Jefferson
>
> java.util.Optional provides a feature that is available in other languages. 
> Since JDO 3.2 will be for Java8+ then it makes sense to add support for this 
> as a "supported persistable type"



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


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

2016-02-12 Thread JIRA

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

Tilmann Zäschke commented on JDO-751:
-

I think there still is a problem when writing {{postcode == null}} in a query. 
If {{postcode}} is of type {{Optional}} and the {{Optional}} references 
{{null}}, should the query match the object (because the Optional references 
null) or not (because the reference to the optional is not null)? In Java this 
is not ambiguous.

> Support for Java8 Optional
> --
>
> Key: JDO-751
> URL: https://issues.apache.org/jira/browse/JDO-751
> Project: JDO
>  Issue Type: New Feature
>  Components: specification, tck
>Reporter: Andy Jefferson
>
> java.util.Optional provides a feature that is available in other languages. 
> Since JDO 3.2 will be for Java8+ then it makes sense to add support for this 
> as a "supported persistable type"



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


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

2016-02-12 Thread Renato Garcia (JIRA)

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

Renato Garcia commented on JDO-751:
---

You shouldn't have null references when using Optional, it defeats the purpose 
of the whole thing, otherwise you would need to check the reference to the 
Optional and then check the value of the Optional.

> Support for Java8 Optional
> --
>
> Key: JDO-751
> URL: https://issues.apache.org/jira/browse/JDO-751
> Project: JDO
>  Issue Type: New Feature
>  Components: specification, tck
>Reporter: Andy Jefferson
>
> java.util.Optional provides a feature that is available in other languages. 
> Since JDO 3.2 will be for Java8+ then it makes sense to add support for this 
> as a "supported persistable type"



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


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

2016-02-12 Thread Renato Garcia (JIRA)

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

Renato Garcia commented on JDO-751:
---

In case we would like to make it not ambiguous in JDOQL how would this be 
implemented in a RDBMS for instance?

How is this related to the "shortcuts" changing semantics, as in "shorcuts" 
meaning auto dereference of Optional fields? 

> Support for Java8 Optional
> --
>
> Key: JDO-751
> URL: https://issues.apache.org/jira/browse/JDO-751
> Project: JDO
>  Issue Type: New Feature
>  Components: specification, tck
>Reporter: Andy Jefferson
>
> java.util.Optional provides a feature that is available in other languages. 
> Since JDO 3.2 will be for Java8+ then it makes sense to add support for this 
> as a "supported persistable type"



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


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

2016-02-12 Thread JIRA

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

Tilmann Zäschke commented on JDO-751:
-

I don't think querying for {{null}} is conceptually wrong. It would be wrong if 
{{Optional}} would be a property of a reference, but it's not a property, it's 
an own class/type. If we don't want people to query for 'null' then we should 
make sure that they can't and forbid it. But I don't think that would be a good 
idea. In Java the semantic is clearly that a reference to Optional is distinct 
from a reference from Optional to something else. I'm not convinced that a 
JDOQL should behave different here.

> Support for Java8 Optional
> --
>
> Key: JDO-751
> URL: https://issues.apache.org/jira/browse/JDO-751
> Project: JDO
>  Issue Type: New Feature
>  Components: specification, tck
>Reporter: Andy Jefferson
>
> java.util.Optional provides a feature that is available in other languages. 
> Since JDO 3.2 will be for Java8+ then it makes sense to add support for this 
> as a "supported persistable type"



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


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

2016-02-12 Thread JIRA

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

Tilmann Zäschke commented on JDO-751:
-

I completely agree, that defeats the purpose of {{Optional}} :-). My argument 
is simply that unfortunately the way that Java implements it, you _can_ have a 
{{null}} reference to an {{Optional}}. Of course JDOQL could implement 
different semantics than Java by ignoring the case that a reference to an 
{{Optional}} can be {{null}}, but it it would still be exactly that: different 
semantics. 

We can of course use different semantic in JDOQL and Java. But considering how 
unlikely it is that a Field is of type {{Optional}} (after all it seems to be 
discouraged by the Java people), I'm not sure that the potential benefits of a 
shortcut are worth the potential future risk of deviating from Java.

Yes, comparing an {{Optional}} to {{null}} seems silly, but that doesn't mean 
that nobody is going to do it or even find a clever use for it.

> Support for Java8 Optional
> --
>
> Key: JDO-751
> URL: https://issues.apache.org/jira/browse/JDO-751
> Project: JDO
>  Issue Type: New Feature
>  Components: specification, tck
>Reporter: Andy Jefferson
>
> java.util.Optional provides a feature that is available in other languages. 
> Since JDO 3.2 will be for Java8+ then it makes sense to add support for this 
> as a "supported persistable type"



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


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

2016-02-12 Thread JIRA

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

Tilmann Zäschke commented on JDO-751:
-

??How is this related to the "shortcuts" changing semantics, as in "shorcuts" 
meaning auto dereference of Optional fields? ??
I think it is related because auto-dereferencing means that you assume that the 
reference to the Optional cannot be null.

??I don't think Optional can reference null, it's either a value or "empty".??
So how would one check for "empty"? Would the only possibility be via 
"isPresent()"? 

??In case we would like to make it not ambiguous in JDOQL how would this be 
implemented in a RDBMS for instance? ??
I don't know. But I'm not sure that the difficulty of implementing a feature in 
an RDBMS should guide the design of an API for object oriented persistence?


> Support for Java8 Optional
> --
>
> Key: JDO-751
> URL: https://issues.apache.org/jira/browse/JDO-751
> Project: JDO
>  Issue Type: New Feature
>  Components: specification, tck
>Reporter: Andy Jefferson
>
> java.util.Optional provides a feature that is available in other languages. 
> Since JDO 3.2 will be for Java8+ then it makes sense to add support for this 
> as a "supported persistable type"



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


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

2016-02-12 Thread JIRA

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

Tilmann Zäschke commented on JDO-751:
-

Just to repeat what was send at the end of the telecon: I favour the dual way 
of allowing both {{postcode!=null}} and {{postcode.isPresent()}} in JDOQL. The 
problem is that this can cause collision if the object referenced by the 
{{Optional}} has the same method names as {{Optional}}. Currently, the only 
problem occurs if the with {{Optional}} because {{List}} also has a get 
method, although with a different signature.

The problem is that, if we allow {{Optional}} methods and at the same time 
allow the short-cut with auto-dereferencing then we may get into trouble in 
future. If we ever think about admitting method calls on domain objects, then 
these could conflict with the methods of {{Optional}}. Similarily, we would be 
in trouble if Java ever decides to add a {{isPresent()}} method to {{List}} or 
{{Map}} (for whatever reason).

Fun question (not a likely use-case): How do we treat 
{{Optional}} where department is null? Should JDOQL do 
double-auto-dereferencing?

> Support for Java8 Optional
> --
>
> Key: JDO-751
> URL: https://issues.apache.org/jira/browse/JDO-751
> Project: JDO
>  Issue Type: New Feature
>  Components: specification, tck
>Reporter: Andy Jefferson
>
> java.util.Optional provides a feature that is available in other languages. 
> Since JDO 3.2 will be for Java8+ then it makes sense to add support for this 
> as a "supported persistable type"



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


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

2016-02-12 Thread JIRA

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

Tilmann Zäschke commented on JDO-751:
-

Maybe it should also be considered whether JDO may at some point want to add 
something like lambdas do JDOQL. In that case, it would be useful to have the 
{{isPresent()}}, {{orElse(...)}} and {{get()}} methods available.

> Support for Java8 Optional
> --
>
> Key: JDO-751
> URL: https://issues.apache.org/jira/browse/JDO-751
> Project: JDO
>  Issue Type: New Feature
>  Components: specification, tck
>Reporter: Andy Jefferson
>
> java.util.Optional provides a feature that is available in other languages. 
> Since JDO 3.2 will be for Java8+ then it makes sense to add support for this 
> as a "supported persistable type"



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


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

2016-02-12 Thread Renato Garcia (JIRA)

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

Renato Garcia commented on JDO-751:
---

{quote}I think it is related because auto-dereferencing means that you assume 
that the reference to the Optional cannot be null.{quote}
Not necessarily, it depends on how you do it. It would be probably something 
{{orElse(null)}} rather then {{get()}} to be compatible with JDOQL handling of 
nulls.
{quote}So how would one check for "empty"? Would the only possibility be via 
"isPresent()"?{quote}
In a query? Either comparing to "empty" using a variable or calling "isPresent" 
if the method is implemented.
{quote}I don't know. But, at least ideally, I'm not sure that the difficulty of 
implementing a feature in an RDBMS should guide the design of an API for object 
oriented persistence?{quote}
Exercising the possible implementations is a good guidance of the practicality 
of the API and helps understand the trade-offs imposed by the API.

> Support for Java8 Optional
> --
>
> Key: JDO-751
> URL: https://issues.apache.org/jira/browse/JDO-751
> Project: JDO
>  Issue Type: New Feature
>  Components: specification, tck
>Reporter: Andy Jefferson
>
> java.util.Optional provides a feature that is available in other languages. 
> Since JDO 3.2 will be for Java8+ then it makes sense to add support for this 
> as a "supported persistable type"



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


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

2016-02-12 Thread Renato Garcia (JIRA)

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

Renato Garcia commented on JDO-751:
---

{quote}Fun question (not a likely use-case): How do we treat 
Optional where department is null? Should JDOQL do 
double-auto-dereferencing?{quote}

Would it be a valid mapping to start with? Is {{List}} valid?

> Support for Java8 Optional
> --
>
> Key: JDO-751
> URL: https://issues.apache.org/jira/browse/JDO-751
> Project: JDO
>  Issue Type: New Feature
>  Components: specification, tck
>Reporter: Andy Jefferson
>
> java.util.Optional provides a feature that is available in other languages. 
> Since JDO 3.2 will be for Java8+ then it makes sense to add support for this 
> as a "supported persistable type"



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


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

2016-02-11 Thread JIRA

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

Tilmann Zäschke commented on JDO-751:
-

??perhaps it should be also true that querying with null on an Optional has 
undefined behaviour; which is not a big deal because in practice since you 
shouldn't be doing it anyway and when you are using Optional this distinction 
becomes irrelevant.??

I think that one of the design goals of JDOQL was to be close to Java. I think 
it's already a bit problematic to introduce shortcuts that have different 
semantics than Java, but I really don't think it's a good idea to intentionally 
prevent simple operations (comparison of Optional to null) in JDOQL that are 
possible in Java and give them different semantics.

On a separate note, I saw that {{Optional}} is not {{Serializable}}, and it 
seems to be only intended (or useful) for lambdas/streams. I even saw someone 
mentioning that they considered calling it {{OptionalReturn}} to indicate that 
it should only be used as return value.

There is one thing that I would find interesting though: The semantic of 
{{Optional}} means that it cannot be modified, i.e. it is an immutable 
reference. Translated to a DBMS, that would mean that {{Optional}} protects a 
reference such that the referenced object cannot be deleted.

In summary, I think {{Optional}} is not intended by the Java designers to be 
serializable, so maybe JDO should not support this either. However, if we do 
support it, I'm still somewhat opposed to shortcuts, because they change the 
semantics. However I would support the non-deletability of referenced objects, 
because that would be an interesting feature and would better reflect the 
semantics of {{Optional}}.

> Support for Java8 Optional
> --
>
> Key: JDO-751
> URL: https://issues.apache.org/jira/browse/JDO-751
> Project: JDO
>  Issue Type: New Feature
>  Components: specification, tck
>Reporter: Andy Jefferson
>
> java.util.Optional provides a feature that is available in other languages. 
> Since JDO 3.2 will be for Java8+ then it makes sense to add support for this 
> as a "supported persistable type"



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


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

2016-02-11 Thread Craig L Russell (JIRA)

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

Craig L Russell commented on JDO-751:
-

I'd like to propose that Optional be strictly a persistence-capable class 
modeling artifact. 

For mapping to the datastore, treat Optional exactly as T, except (as Andy 
suggests) require that the datastore accept null as a value. When instantiating 
an instance from the datastore, the persistence implementation would get the 
value v from the datastore and assign the field f = Optional.ofNullable(v). 
When storing the field in the datastore, the persistence implementation would 
store the result of v = f.isPresent()?f.get():null.

With this proposal, there is no change to JDOQL (Andy's "alternative"). The 
query language already protects against accidentally dereferencing null values 
and provides for comparing values for null.

This proposal allows users to model persistent classes with possible null 
valued fields using the shorthand Optional features. It seems to me that 
Optional really is just a slick way to avoid using ==null and instead use 
ifPresent and other object-oriented methods. 

> 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

2016-02-10 Thread JIRA

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

Tilmann Zäschke commented on JDO-751:
-

But what happens in your example if {{foo}} is a variable and is {{null}}? 
Could {{foo}} also be an {{Optional}} instance?
I think the shortcut looks nice, but I'm not convinced it can be implemented 
without inconsistencies. 

I also think the idea of {{Optional}} is to provide some additional semantics. 
If someone is happy using the shortcuts in queries then they should probably 
use the same shortcuts in Java. It also means that they are probably not 
interested in the additional semantics and should probably not use {{Optional}} 
in the first place. Would you agree?



> 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

2016-02-10 Thread Renato Garcia (JIRA)

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

Renato Garcia commented on JDO-751:
---

{quote}
But what happens in your example if foo is a variable and is null?
{quote}
It would just filter the {{Address}} instances that have postCode {{null}}, in 
a scenario that postCode is a *non*-{{Optional}}.

On the other hand if {{address}} is {{empty}}, it would have same behaviour of 
nullable fields on navigation.

{quote}
Could foo also be an Optional instance?
{quote}
Yes, as long as {{postCode}} is of type {{Optional}} that would fine. The 
type matching should be just like the any other and in this case it should 
accept {{null}}, since Java does as well, and {{Optional}}, but not {{T}}.

Even though the Java compiler doesn't prevent you from assigning {{null}} to an 
{{Optional}} reference it is considered bad practice or semantically wrong (it 
can/should be handled by static analysis tools). So I think the same idea 
should apply to the query. Therefore, while I think that {{"date == null"}} 
shouldn't be the same as {{!date.isPresent()}}, considering that it can be 
cumbersome to implement the difference between {{null}} and {{empty}} in some 
datastores(unless you store the empty state), like RDBMS for instance, perhaps 
it should be also true that querying with {{null}} on an Optional has undefined 
behaviour; which is not a big deal because in practice since you shouldn't be 
doing it anyway and when you are using {{Optional}} this distinction becomes 
irrelevant.

{quote}
I think the shortcut looks nice, but I'm not convinced it can be implemented 
without inconsistencies.
{quote}
I think the {{Optional}} deference/shortcuts are similar to what is done with 
getters. Instead of writing(assuming no Optional involved):
{{person.getAddress().getPostCode() == foo}} you can write 
{{person.address.postCode == foo}}, which is not consistent with the respective 
Java code too, but very convenient.

The deference would only be for navigation on the filter, but on results would 
still return an Optional of course. I don't see this as inconsistent but it's 
definitely a special case. In my opinion it pays off to have a special 
treatment (unless we come up with something better than deferencing it with 
get) given that when you decide to use Optional instead of null to represent 
nullability/optionality, it becomes very common pattern on your model, so 
providing a special syntax makes a lot of sense.

{quote}
I also think the idea of Optional is to provide some additional semantics. If 
someone is happy using the shortcuts in queries then they should probably use 
the same shortcuts in Java. It also means that they are probably not interested 
in the additional semantics and should probably not use Optional in the first 
place. Would you agree?
{quote}
I agree in principle, however it doesn't mean that you can't have a nicer 
syntax for it. I believe that the idea is that if you are using {{Optional}} 
you would use a more functional style {{map/filter}} instead of calling 
{{isPresent()}} and {{get()}} -- but I'm not sure how this would apply to the 
query; so you kind of have the shortcuts, might not be as good as in Scala or 
other JVM language with more support for functional constructs, but it is still 
there.

> 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

2016-02-09 Thread Andy Jefferson (JIRA)

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

Andy Jefferson commented on JDO-751:


>From Apache JDO "minutes" 

Q. Does it make sense to support Optional as a persistent type? It would need 
to map to a nullable datastore value. So Optional can be the type of a 
persistent field iff T can be the type of a persistent field. Does it make 
sense to support Optional as a first class object? If an Employee has a 
field Optional can the field be treated as first class? 
Q. Could Employee.getDepartment() return an Optional? 

Answer : yes to both. A user can have fields of types like Optional, 
Optional and would expect these to be mapped in the datastore to a column 
that accepts NULLs, and of the equivalent type of T. Similarly they could have 
a 1-1 relation via a field of type Optional.


The other aspect of this would be in terms of JDOQL and queryability of such 
fields. Following the idea that JDOQL attempts to have Java syntax then we 
should have methods
optionalField.isPresent()  returning a BooleanExpression
optionalField.get() returning an expression of the type of the T type, so 
StringExpression, DateExpression, etc.

The alternative to this is just to let the user do "== NULL" to check if a 
value is present. Comments?

> 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

2016-02-09 Thread JIRA

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

Tilmann Zäschke commented on JDO-751:
-

I completely agree with the answers.
Just to clarify the first question: I see that 'Optional' should be allowed to 
reference persistence classes (as FCOs) as well as SCOs (such as String, ...). 
But I guess Optional itself should not be a persistent type? 

Also, I think we have to decide whether we want to distinguish the case that 
the reference to Optional could be null vs Optional references a null:
{{private Optional date;}} -> {{date==null}} vs {{date.isPresent}}.

This is also important for queries, because again {{"date==null"}} would mean 
something different than {{"date.isPresent()"}}


> 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

2016-02-09 Thread Renato Garcia (JIRA)

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

Renato Garcia commented on JDO-751:
---

{quote}
Just to clarify the first question: I see that 'Optional' should be allowed to 
reference persistence classes (as FCOs) as well as SCOs (such as String, ...). 
But I guess Optional itself should not be a persistent type?
{quote}

Optional type can be seen as a collection containing zero or one item, so 
perhaps it would make sense to address them the same way the spec addresses the 
other collection types.

Regarding JDOQL support, I kind of like the idea of supporting methods like 
isPresent and make a distinction as Tilmann has mentioned above.

Also, given the following scenario: Person FCO with an Optional
I think it would probably be nice to be able to just write something like this 
in the query:
{code:java}
person.address.postCode = foo
{code}
instead of having to deference the value using get

> 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)