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