Re: Java 8 Date/Time API Extension Methods

[Joe Wolf]

I'm all on board for integrating into Groovy, and I'm letting that drive
design decisions as I finish up the changes. I appreciate the feedback on
the API--I will definitely take it all under consideration. Perhaps we
should move integration-related discussions over to the dev mailing list.

-Joe

On Mon, Jun 26, 2017 at 7:51 AM, Guillaume Laforge <glafo...@gmail.com>
wrote:

> I also think it's sane to keep the Java 8 ordering in this case.
>
> Even if we can use ranges, keeping upto / downto in addition would be kind
> to people used to using them.
>
> Anyhow, very nice work!
> I still believe we need to integrate it to Groovy core :-)
>
> Guillaume
>
> On Mon, Jun 26, 2017 at 8:10 AM, Ahm Avoby <aliencheck...@gmail.com>
> wrote:
>
>> Hi Jim,
>>
>> @static parse(): I am with you on keeping the Java 8 API ordering, but I
>> would not jettison the upto and downto methods, as to not confuse people
>> switching from Java 8 to Groovy.
>>
>> Cheers,
>> Ahm
>>
>>
>>
>> Joe Wolf <joew...@gmail.com> schrieb am So., 25. Juni 2017, 23:32:
>>
>>> Goodtimes 1.1 is out with new extension methods on the zone-based types,
>>> effectively covering the entire java.time.* package (except for Clock,
>>> which I haven't found need to extend). I'd say I'm about 98% content with
>>> the API.
>>>
>>> I'm mulling the addition of static parse() methods akin to the Groovy
>>> JDK's Date.parse(String format, String input) method, but am wrestling with
>>> argument ordering. Date.parse accepts the format as the first argument; the
>>> new java.time API parse methods accept the date/time string first. Although
>>> I've aimed to be consistent with the Groovy JDK thus far, I'm leaning
>>> towards following the Java 8 API ordering in this case.
>>>
>>> On the other side of the coin, I am contemplating jettisoning the upto
>>> and downto methods. Since the java.time types are Comparable and goodtimes
>>> adds next() and previous() methods, the range operator can be used to
>>> replicate their function
>>>
>>> earlier.upto(later) {} --> (earlier..later).each {}
>>> later.downto(earlier) {} --> (later..earlier).each {}
>>>
>>> I'm also questioning the existence of the getAt(int calendarField)
>>> methods. On the downside, it's munging the older java.util API with the
>>> new; on the upside, I don't have to explicitly import
>>> java.time.temporal.ChronoField. java.util.Calendar comes for free.
>>>
>>> -Joe
>>>
>>> On Fri, Jun 9, 2017 at 8:51 AM, Guillaume Laforge <glafo...@gmail.com>
>>> wrote:
>>>
>>>> Keep us updated on the new extensions, and once you're happy with what
>>>> you have come up with, I believe it'd really be awesome to have it
>>>> integrated.
>>>>
>>>> Guillaume
>>>>
>>>>
>>>> On Fri, Jun 9, 2017 at 5:07 AM, Joe Wolf <joew...@gmail.com> wrote:
>>>>
>>>>> +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 working to add extension methods to the
>>>>> java.time types involving ZoneId and ZoneOffset. I hope to have that
>>>>> completed in a couple of weeks or so.
>>>>>
>>>>> -Joe
>>>>>
>>>>> On Thu, Jun 8, 2017 at 7:52 PM, Mario Garcia <mario.g...@gmail.com>
>>>>> wrote:
>>>>>
>>>>>> +1
>>>>>>
>>>>>> I think Many Groovy applications could benefit from having this in
>>>>>> Groovy.
>>>>>>
>>>>>> 2017-06-09 1:02 GMT+02:00 Paul King <pa...@asert.com.au>:
>>>>>>
>>>>>>> +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č <dinko.sr...@gmail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> On 8 June 2017 at 13:34, Russel Winder <rus...@winder.org.uk>

Re: Java 8 Date/Time API Extension Methods

[Joe Wolf]

Goodtimes 1.1 is out with new extension methods on the zone-based types,
effectively covering the entire java.time.* package (except for Clock,
which I haven't found need to extend). I'd say I'm about 98% content with
the API.

I'm mulling the addition of static parse() methods akin to the Groovy
JDK's Date.parse(String format, String input) method, but am wrestling with
argument ordering. Date.parse accepts the format as the first argument; the
new java.time API parse methods accept the date/time string first. Although
I've aimed to be consistent with the Groovy JDK thus far, I'm leaning
towards following the Java 8 API ordering in this case.

On the other side of the coin, I am contemplating jettisoning the upto and
downto methods. Since the java.time types are Comparable and goodtimes adds
next() and previous() methods, the range operator can be used to replicate
their function

earlier.upto(later) {} --> (earlier..later).each {}
later.downto(earlier) {} --> (later..earlier).each {}

I'm also questioning the existence of the getAt(int calendarField) methods.
On the downside, it's munging the older java.util API with the new; on the
upside, I don't have to explicitly import java.time.temporal.ChronoField.
java.util.Calendar comes for free.

-Joe

On Fri, Jun 9, 2017 at 8:51 AM, Guillaume Laforge <glafo...@gmail.com>
wrote:

> Keep us updated on the new extensions, and once you're happy with what you
> have come up with, I believe it'd really be awesome to have it integrated.
>
> Guillaume
>
>
> On Fri, Jun 9, 2017 at 5:07 AM, Joe Wolf <joew...@gmail.com> wrote:
>
>> +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 working to add extension methods to the
>> java.time types involving ZoneId and ZoneOffset. I hope to have that
>> completed in a couple of weeks or so.
>>
>> -Joe
>>
>> On Thu, Jun 8, 2017 at 7:52 PM, Mario Garcia <mario.g...@gmail.com>
>> wrote:
>>
>>> +1
>>>
>>> I think Many Groovy applications could benefit from having this in
>>> Groovy.
>>>
>>> 2017-06-09 1:02 GMT+02:00 Paul King <pa...@asert.com.au>:
>>>
>>>> +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č <dinko.sr...@gmail.com>
>>>> wrote:
>>>>
>>>>> On 8 June 2017 at 13:34, Russel Winder <rus...@winder.org.uk> wrote:
>>>>> > On Thu, 2017-06-08 at 13:18 +0200, Dinko Srkoč wrote:
>>>>> >> On 8 June 2017 at 13:09, Russel Winder <rus...@winder.org.uk>
>>>>> 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 that all new code eschews
>>>>> >> > java.util.Date
>>>>> >> > and all the Calendar stuff, and uses java.time for everything time
>>>>> >> > and
>>>>> >> > date related?
>>>>> >>
>>>>> >> I think this falls into a category of "hope" or "wish", rather than
>>>>> >> "assumption" :-)
>>>>> >
>>>>> > True, but I was hoping that unlike a large percentage of Java
>>>>> > developers who are hugely reluctant to learn anything new they do not
>>>>> > already know (*), Groovy developers were very much into using the
>>>>> best
>>>>> > new idiomatic ways of doing things (well except for stuff that is
>>>>> just
>>>>> > fashionably trendy for a few days) and keeping their codebases up to
>>>>> > date with up-to-date Groovy.
>>>>> >
>>>>> > Please do not shatter my illusions.
>>>>>
>>>>> haha!
>>>>>
>>>>> Okay, I could convince myself that it is indeed so with Groovy
>>>>> developers. :-)
>>>>>
>>>>> >
>>>>> >
>>>>> >
>>>>> > (*) And are thus part of the legacy problem.
>>>>> >
>>>>> > --
>>>>> > Russel.
>>>>> > 
>>>>> =
>>>>> > Dr Russel Winder  t: +44 20 7585 2200   voip:
>>>>> sip:russel.win...@ekiga.net
>>>>> > 41 Buckmaster Roadm: +44 7770 465 077   xmpp:
>>>>> rus...@winder.org.uk
>>>>> > London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
>>>>>
>>>>
>>>>
>>>
>>
>
>
> --
> Guillaume Laforge
> Apache Groovy committer & PMC Vice-President
> Developer Advocate @ Google Cloud Platform
>
> Blog: http://glaforge.appspot.com/
> Social: @glaforge <http://twitter.com/glaforge> / Google+
> <https://plus.google.com/u/0/114130972232398734985/posts>
>

Re: Slashy strings in GroovyConsole

[Joe Wolf]

Also be careful when using slashy Strings with path names that start with a
lowercase "u"

They'll get interpreted as a unicode character escape, e.g. /c:\users/
--> TokenStreamIOException: Did not find four digit hex character code.

(BTW, I'm glad to see there are other GroovyConsole users on Windows out
there)

-Joe

On Wed, Jun 14, 2017 at 6:32 AM, Paul King  wrote:

> What bo zhang said or use dollar slashy string.
>
> Cheers, Paul.
>
> On Wed, Jun 14, 2017 at 7:37 PM, bo zhang  wrote:
>
>> def scriptDir = /C:\Folder1\My Documents\Folder2\Version\etc\//
>>
>> note the last slash. \/ is escaping /
>>
>> On Wed, Jun 14, 2017 at 4:44 PM, Dmytro Shyshchenko > > wrote:
>>
>>> Long time ago I was using slashy strings in my groovy scripts for the
>>> paths on Windows. Somehting like this:
>>> def scriptDir = /C:\Folder1\My Documents\Folder2\Version\etc\/
>>>
>>> However in the recent versions, like 2.3.6 or 2.4.11, I can no longer
>>> execute those scripts via a GroovyConsole. It always gave me an error
>>> pointing to the last charecter of the script. Like this:
>>> unexpected char: 0x at line: 19, column: 13
>>> which was a bit misleading...
>>>
>>> When I change the paths to a "normal" srtings, everything works fine, as
>>> it was before.
>>> def scriptDir = "C:\\Folder1\\My Documents\\Folder2\\Version\\etc\\"
>>>
>>> Is it a bug? Shall I report it?
>>>
>>>
>>>
>>
>

Re: Java 8 Date/Time API Extension Methods

[Joe Wolf]

+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 working to add extension methods to the java.time
types involving ZoneId and ZoneOffset. I hope to have that completed in a
couple of weeks or so.

-Joe

On Thu, Jun 8, 2017 at 7:52 PM, Mario Garcia  wrote:

> +1
>
> I think Many Groovy applications could benefit from having this in Groovy.
>
> 2017-06-09 1:02 GMT+02:00 Paul King :
>
>> +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 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 that all new code eschews
>>> >> > java.util.Date
>>> >> > and all the Calendar stuff, and uses java.time for everything time
>>> >> > and
>>> >> > date related?
>>> >>
>>> >> I think this falls into a category of "hope" or "wish", rather than
>>> >> "assumption" :-)
>>> >
>>> > True, but I was hoping that unlike a large percentage of Java
>>> > developers who are hugely reluctant to learn anything new they do not
>>> > already know (*), Groovy developers were very much into using the best
>>> > new idiomatic ways of doing things (well except for stuff that is just
>>> > fashionably trendy for a few days) and keeping their codebases up to
>>> > date with up-to-date Groovy.
>>> >
>>> > Please do not shatter my illusions.
>>>
>>> haha!
>>>
>>> Okay, I could convince myself that it is indeed so with Groovy
>>> developers. :-)
>>>
>>> >
>>> >
>>> >
>>> > (*) And are thus part of the legacy problem.
>>> >
>>> > --
>>> > Russel.
>>> > 
>>> =
>>> > Dr Russel Winder  t: +44 20 7585 2200   voip:
>>> sip:russel.win...@ekiga.net
>>> > 41 Buckmaster Roadm: +44 7770 465 077   xmpp: rus...@winder.org.uk
>>> > London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
>>>
>>
>>
>

Re: Java 8 Date/Time API Extension Methods

[Joe Wolf]

Thanks Søren and Guillaume. I'm glad to finally contribute something to the
Groovy community!

On Sun, May 7, 2017 at 4:14 PM, Guillaume Laforge <glafo...@gmail.com>
wrote:

> This is indeed cool, and I'm wondering if it shouldn't be part of Groovy
> itself directly :-)
>
> On Sun, May 7, 2017 at 10:09 PM, Søren Berg Glasius <soe...@glasius.dk>
> wrote:
>
>> Well done! Thank you for sharing!
>>
>> /Søren
>>
>>
>> On Sat, 6 May 2017 at 22:30 Joe Wolf <joew...@gmail.com> wrote:
>>
>>> Hi, I want to announce the 1.0 release of an OSS project I've been
>>> working on called goodtimes.
>>>
>>> The Groovy JDK has always been one of my favorite parts of Groovy, but
>>> it currently lacks support for newer Java 8 classes. Goodtimes fills some
>>> of this gap until the GDK is updated by providing extension methods for the
>>> Java 8 Date/Time API akin to those available for java.util.Date and
>>> Calendar.
>>>
>>> Source and documentation are hosted on GitHub: https://github.com/bdk
>>> osher/goodtimes
>>>
>>> Just add the dependency to your classpath to give it a try (assuming
>>> you're on Java 8, of course).
>>>
>>> @Grab('com.github.bdkosher:goodtimes:1.0')
>>>
>>> compile 'com.github.bdkosher:goodtimes:1.0'
>>>
>>> -Joe
>>> @bdkosher
>>>
>> --
>> Best regards / Med venlig hilsen,
>> Søren Berg Glasius
>>
>> Hedevej 1, Gl. Rye, 8680 Ry, Denmark
>> Mobile: +45 40 44 91 88 <+45%2040%2044%2091%2088>, Skype: sbglasius
>> --- Press ESC once to quit - twice to save the changes.
>>
>
>
>
> --
> Guillaume Laforge
> Apache Groovy committer & PMC Vice-President
> Developer Advocate @ Google Cloud Platform
>
> Blog: http://glaforge.appspot.com/
> Social: @glaforge <http://twitter.com/glaforge> / Google+
> <https://plus.google.com/u/0/114130972232398734985/posts>
>

Java 8 Date/Time API Extension Methods

[Joe Wolf]

Hi, I want to announce the 1.0 release of an OSS project I've been working
on called goodtimes.

The Groovy JDK has always been one of my favorite parts of Groovy, but it
currently lacks support for newer Java 8 classes. Goodtimes fills some of
this gap until the GDK is updated by providing extension methods for the
Java 8 Date/Time API akin to those available for java.util.Date and
Calendar.

Source and documentation are hosted on GitHub: https://github.com/bdkosher/
goodtimes

Just add the dependency to your classpath to give it a try (assuming you're
on Java 8, of course).

@Grab('com.github.bdkosher:goodtimes:1.0')

compile 'com.github.bdkosher:goodtimes:1.0'

-Joe
@bdkosher