Re: [threeten-develop] API Integration

[Douglas S. <dou...@or...>]

The JDBC spec lead and the Oracle member of the JDBC EG (me) are both 
members of the JSR-310 EG and are actively following it. All members 
of the JDBC EG are committed to fully supporting 310 in JDBC in the 
same release. While JDBC has its own date/time representations, they 
aren't very good and we await 310 anxiously. We foresee no problems 
with supporting 310 in JDBC.

With respect to converting between legacy types and 310 types, my 
personal preference is to add conversion methods to the legacy types. 
Example:

in java.util.Date

   public static Date valueOf(javax.time.LocalDateTime ldt) { ... }
   public javax.LocalDateTime toLocalDateTime() { ... }

Others prefer constructors to static factory methods while others 
prefer adding the conversion methods to the thing you have. Example:

in javax.LocalDateTime

   public java.util.Date toJavaUtilDate() { ... }

I prefer to put the conversion methods in the legacy classes to avoid 
cluttering the new API with methods that will over time become less 
and less useful. Let's put the methods with declining utility in the 
classes that are also of declining utility.

Douglas


At 12:55 PM 12/14/2011, Richard Warburton wrote:
> From the "Threeten API adoption" email:
>
> > For easy incremental adoption, the new Date/time classes need to 
> be usable with
> > the current text/locale formatting capabilities in 
> java.util.Formatter and java.text
> > but that is a topic by itself related to integration with 
> existing classes.
>
>I agree that this is a different topic to that of your other email, 
>but it is probably deserving of a thread in its own right.  When 
>James and I gave a JSR 310/TCK overview talk a few weeks back the 
>one thing that people were concerned about that I feel this project 
>doesn't have a particularly strong handle on is the integration 
>story.
>
>In addition to the formatting, there's also the issue of what's 
>happening with the previous Datetime classes.  Aside from the 
>presumed deprecation there's the issue of converting between 
>instances of the old API and the new API.  I consider this to be 
>somewhat necessary for anyone attempting incremental adoption.  Is 
>anyone aware of any lessons/problems/solutions from Jodatime that 
>would be applicable here?
>
>The final, and most thorny, issue is the database API 
>integration.  As far as I'm aware, the current situation is that the 
>JDBC API isn't controlled by this JSR and already has its own class 
>for representing a Date.  This seems most undesirable to me.
>
>Firstly I'm not sure whether JSR 310 having say some utility methods 
>that generate 'java.sql.Date' instances feels like smooth enough 
>integration at the API level.
>
>Secondly, there's a potential issue about the 'long of seconds + int 
>of nanos' instant representation in JSR 310 being more future proof 
>and precise than databases representing instants using the 'long of 
>milliseconds' approach.  I'm concerned that just serialising to a 
>database in a way that loses precision then makes an object that has 
>been deserialized from a database representation not necessarily 
>equal to the original value.  There is also the option of trying to 
>convert to DECIMAL type fields, with the necessary size, but that 
>might not be considered an optimal approach since you're not 
>maintaining the typing of field values from your language in your 
>database.  I'm also not aware of what the performance implications 
>of using DECIMAL would be, which is also a question that might be 
>DB-dependent.  There's also potential compatibility and 
>interoperability issues with this approach.
>
>Thirdly there's also the issue of JPA, which seems to have similar 
>issues to JDBC integration.  As far as I can tell JSR 338 is 
>developing an improved release of the JPA API, but the deadlines for 
>things like their EDR have passed without anything linked from their 
>jcp.org page, so I don't know what the current state of play is.
>
>My main concern is that without the appropriate communication with 
>the JDBC and JPA teams the JSR 310 API won't serve the complete 
>needs of its users.  Given the schedules that we're working on, I 
>feel that such a discussion would be best facilitated by being 
>started as soon as possible.  I don't know if any existing 
>conversations have happened, and if they have it would be fantastic 
>to know about the parameters of their discussion and if any 
>conclusions were reached.
>
>On the assumption that no ideal conclusions have been reached so 
>far, I'd like to suggest that we discuss what we'd like in terms of 
>prospective changes to their APIs in order to facilitate JSR 310 
>interoperability.  We can then evaluate these proposals in friendly 
>concert with the maintainers of JDBC and JPA, and see what changes 
>they are open to.
>
>regards,
>
>   Richard
>------------------------------------------------------------------------------
>Cloud Computing - Latest Buzzword or a Glimpse of the Future?
>This paper surveys cloud computing today: What are the benefits?
>Why are businesses embracing it? What are its payoffs and pitfalls?
>http://www.accelacomm.com/jaw/sdnl/114/51425149/
>
>_______________________________________________
>threeten-develop mailing list
>thr...@li...
>https://lists.sourceforge.net/lists/listinfo/threeten-develop