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

2016-02-11 Thread Michael Bouschen 
Hi,

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

Dial-in numbers are:
US Toll free: 866 682-4770
Germany Frankfurt +49 69 222 216 106
Germany Munich: +49 89 1430 2323
Germany Toll free: 08006648515
Switzerland Geneva: +41 445804003
Switzerland Toll free: 0800650026
Oracle Conferencing - Operator-Free Global Access Num(Other countries by 
request)

To place the call:
1. Call the toll free number.
2. Enter the conference number 939-3689#
3. Enter the security code #

We use the conference call for audio and use Google Hangouts for screen sharing 
and video.
The Google Hangouts URL for the meeting: http://goo.gl/sCKJaS

Agenda:
1. JDO 3.1: Need to go through change lists in JIRA for 3.1 RC1 and 3.1 to 
prepare JCP Change Log
2. JDO social media properties (see email from Matthew)
3. JDO-751 "Support for Java8 Optional" 
https://issues.apache.org/jira/browse/JDO-751
4. Any news on JDO-749 "Support for java.time types, and querying using 
associated methods" https://issues.apache.org/jira/browse/JDO-749?
5. Any news on JIRA JDO-747 "Behavior of delete() with multiple concurrent 
Transactions" https://issues.apache.org/jira/browse/JDO-747?
6. Other issues

Action Items from weeks past:
[Oct 30 2015] AI Craig: File a maintenance review with JCP
[May 15 2015] AI Craig Spec change for roll back an active transaction when 
closing a persistence manager (JDO-735)  
[Apr 17 2015] AI Craig: Oracle spec page on JDO need to be updated once the JCP 
Maintenance Release for JDO 3.1 is published
[Oct 17 2014] AI Matthew any updates for "Modify specification to address NoSQL 
datastores": https://issues.apache.org/jira/browse/JDO-651?
[Feb 28 2014] AI Everyone: take a look at 
https://issues.apache.org/jira/browse/JDO-712
[Feb 28 2014] AI Everyone: take a look at 
https://issues.apache.org/jira/browse/JDO-625
[Dec 13 2013] AI Craig file a JIRA for java.sql.Blob and java.sql.Clob as 
persistent field types
[Aug 24 2012] AI Craig update the JIRAs JDO-689 JDO-690 and JDO-692 about 
JDOHelper methods. In process.

Regards Michael 

-- 
*Michael Bouschen*
*Prokurist*

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

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

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

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

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&focusedCommentId=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] [Comment Edited] (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&focusedCommentId=15142722#comment-15142722
 ] 

Tilmann Zäschke edited comment on JDO-751 at 2/11/16 1:31 PM:
--

??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 meaning in JDOQL.

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}}.


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

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