Re: Java 8 Date/Time API Extension Methods

Grails supports the java 8 date classes with a grails-java8 plugin http://plugins.grails.org/plugin/grails/grails-java8 > On Jun 8, 2017, at 11:21 PM, Tankerbay wrote: > > Is there still a legacy issue in that many

Re: Java 8 Date/Time API Extension Methods

hibernate 5 supports java.time via hibernate-java8.jar more info at https://www.thoughts-on-java.org/hibernate-5-date-and-time/ JPA doesn't yet till 2.2 On Thu, Jun 8, 2017 at 11:21 PM, Tankerbay wrote: > Is there still a legacy issue in that many ORMs (including the

Re: Java 8 Date/Time API Extension Methods

Is there still a legacy issue in that many ORMs (including the version of Grails I'm using) tend to use java.sql.Date which has the benefit of extending java.util.Date? Is there Hibernate support for java.time yet? On Thu, Jun 8, 2017 at 8:07 PM, Joe Wolf wrote: > +1 for me.

Re: Java 8 Date/Time API Extension Methods

+1 for me. I think it's a good idea. Not everything in the current API may be worthwhile to have as part of Groovy proper, though. For example, the bridging methods from the java.time classes back to Date and Calendar could be unnecessarily promoting the latter's usage. By the way, I'm currently

Re: Groovy 2.5.0-beta-1 released

And it's there now: http://groovy-lang.org/releasenotes/groovy-2.5.html We might make a nicer fleshed out version for some of those points before the final release - but at least it's there now. Cheers, Paul. On Fri, Jun 9, 2017 at 10:29 AM, Paul King wrote: > > The

Re: Groovy 2.5.0-beta-1 released

The normal practice is to mark the related Jira issue(s) with a 'breaking' label. We sometimes don't do that if the previous behavior was deemed a bug. In any case, I have marked both the relevant issues with the label now. I also updated the release notes to list those two issues under breaking

Re: Java 8 Date/Time API Extension Methods

+1 from me, but I'd be keen to hear Joe's thoughts? Cheers, Paul. On Thu, Jun 8, 2017 at 10:37 PM, Dinko Srkoč wrote: > On 8 June 2017 at 13:34, Russel Winder wrote: > > On Thu, 2017-06-08 at 13:18 +0200, Dinko Srkoč wrote: > >> On 8 June 2017 at

RE: Groovy 2.5.0-beta-1 released

I see there is Elvis support for Optional, which is pretty cool. But when there are breaking changes like this that affect runtime behavior without a change in code, is there a place where this is documented when the release comes out? It would be a nice section to include for Groovy 2.5

Re: Java 8 Date/Time API Extension Methods

On 8 June 2017 at 13:34, Russel Winder wrote: > On Thu, 2017-06-08 at 13:18 +0200, Dinko Srkoč wrote: >> On 8 June 2017 at 13:09, Russel Winder wrote: >> > On Wed, 2017-06-07 at 14:38 +, Søren Berg Glasius wrote: >> > > I think it makes perfect

Re: Java 8 Date/Time API Extension Methods

Hi Joe, Thanks for your awesome work. I like it. Cheers, Daniel.Sun -- View this message in context: http://groovy.329449.n5.nabble.com/Java-8-Date-Time-API-Extension-Methods-tp5740663p5741533.html Sent from the Groovy Users mailing list archive at Nabble.com.

Re: Java 8 Date/Time API Extension Methods

On Thu, 2017-06-08 at 13:18 +0200, Dinko Srkoč wrote: > On 8 June 2017 at 13:09, Russel Winder wrote: > > On Wed, 2017-06-07 at 14:38 +, Søren Berg Glasius wrote: > > > I think it makes perfect sense that you can do the same > > > calculations > > > with > > >

Re: Java 8 Date/Time API Extension Methods

On 8 June 2017 at 13:09, Russel Winder wrote: > On Wed, 2017-06-07 at 14:38 +, Søren Berg Glasius wrote: >> I think it makes perfect sense that you can do the same calculations >> with >> java.time.* as you can with java.util.Date >> > > Shouldn't it be fair to assume

Re: Java 8 Date/Time API Extension Methods

On Wed, 2017-06-07 at 14:38 +, Søren Berg Glasius wrote: > I think it makes perfect sense that you can do the same calculations > with > java.time.* as you can with java.util.Date > Shouldn't it be fair to assume that all new code eschews java.util.Date and all the Calendar stuff, and uses