Re: [DISCUSS] Groovy 2.6 potential retirement to focus on Groovy 3.0

[Wilson MacGyver]

I too vote for option 3.

On Thu, Jun 14, 2018 at 12:49 PM, Cédric Champeau  wrote:

> I vote for option 3
>
> Le jeu. 14 juin 2018 à 18:46, Russel Winder  a
> écrit :
>
>> On Wed, 2018-06-13 at 14:53 -0400, Keith Suderman wrote:
>> > >
>> […]
>> > How about an option #4.  If you are planning to do one more release of
>> 2.6.0
>> > anyway just drop the 'alpha' from the name and announce that it is the
>> first
>> > and last 2.6.x release expected.
>> >
>>
>> I think this would be a bad idea. We haven't had any beta releases, nor RC
>> releases. To jump to a final release strikes me as failure of proper
>> process.
>>
>> Also leaving 2.6.0-alpha-3 as the last 2.6 release clearly indicates it
>> is a
>> retired version series. It also leaves it open much better for someone to
>> pick
>> it up should they so wish.
>>
>> --
>> Russel.
>> ===
>> Dr Russel Winder  t: +44 20 7585 2200
>> 41 Buckmaster Road
>> 
>> m: +44 7770 465 077
>> London SW11 1EN, UK   w: www.russel.org.uk
>>
>


-- 
Omnem crede diem tibi diluxisse supremum.

Re: Java survey, show your Groovy love ;-)

[Wilson MacGyver]

honestly the poll looks like a attempt to get a list of email address for
security/audit consulting  :)

On Sat, May 12, 2018 at 11:43 AM, Russel Winder 
wrote:

> On Sat, 2018-05-12 at 10:51 -0400, Keegan Witt wrote:
> > It's unfortunate it won't let you choose multiple primary application
> > languages, I think it's often an app is a mix of Java and Groovy.
> >
>
> There are so many assumptions explicit and implicit in the questions that
> there is essentially no usefulness at all to the results: the results will
> be
> biased to meet some agenda of the setter of the poll.
>
> --
> Russel.
> ==
> Dr Russel Winder  t: +44 20 7585 2200
> 41 Buckmaster Roadm: +44 7770 465 077
> London SW11 1EN, UK   w: www.russel.org.uk
>



-- 
Omnem crede diem tibi diluxisse supremum.

Re: Java 8 Date/Time API Extension Methods

[Wilson MacGyver]

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


>>>
>>
>


-- 
Omnem crede diem tibi diluxisse supremum.

Re: total internationalisation of Groovy

[Wilson MacGyver]

wow, the Mandarin one is pretty good :)

On Wed, Mar 29, 2017 at 6:04 PM, Guillaume Laforge 
wrote:

> Arabic, Mandarin and Emoji are pretty fun! Nicely done! :-)
>
> Guillaume
>
>
> On Fri, Mar 24, 2017 at 5:20 PM, frenchy48  wrote:
>
>> I implemented a funny experiment on top of Groovy: using my tool beginners
>> can completely program in their own language (I mean everything is
>> translated).
>> You can take a look of this experiment at: http://scrountch.info
>> the implementation is not extremely efficient (or well written) but I
>> consider it an amusing experiment.
>> I was wondering if it could be something that could be implemented in
>> standard Groovy: if an option is present the code could look for i18N
>> properties and be translated (get a look at arabic! the translation is
>> googlesque  -I forgot the arabic I learned at school- but the overall
>> result
>> is startling!)
>> (I know: I will take lot of flak from people who think that english is
>> enough  so please do not shoot the sitting duck!)
>>
>>
>>
>> -
>> member of Grumpy Old Programmers
>> --
>> View this message in context: http://groovy.329449.n5.nabble
>> .com/total-internationalisation-of-Groovy-tp5739335.html
>> Sent from the Groovy Users mailing list archive at Nabble.com.
>>
>
>
>
> --
> Guillaume Laforge
> Apache Groovy committer & PMC Vice-President
> Developer Advocate @ Google Cloud Platform
>
> Blog: http://glaforge.appspot.com/
> Social: @glaforge  / Google+
> 
>



-- 
Omnem crede diem tibi diluxisse supremum.

Re: Maven coordinates going forward

[Wilson MacGyver]

as I recall, there are also rules about jigsaw not allowing same package
path from multiple modules. It's not till java 9, but that maybe a concern.

On Mon, Mar 27, 2017 at 3:28 PM, Guillaume Laforge 
wrote:

> Just an added note on the topic of potential package name changes.
>
> In the past, we've had to move some AST transformations from groovy.lang
> to groovy.transforms, and we managed to make that transition without too
> much harm.
> Similarly to what we did on that occasion, we could offer a compatibility
> module that would just delegate classes from old packages to classes of the
> new packages. And once you've had the time to make the migration, you'd
> just remove the compatibility module.
> We could also have more complex solutions involving bytecode rewriting.
>
> But at some point, it'll really look ridiculous to still have org.codehaus
> here and there, although codehaus' already been long gone already.
>
> So package name changes are not all black'n white.
> There are possible shades of gray :-)
>
> Guillaume
>
>
> On Mon, Mar 27, 2017 at 9:03 PM, Winnebeck, Jason <
> jason.winneb...@windstream.com> wrote:
>
>> I don’t know if it was totally clear from my previous mails, but I agree
>> on not changing the package names, unless breaking changes are required and
>> the package names need to change to preserve the ability of Groovy 1.x/2.x
>> code to co-exist, avoiding the “Python 3 Effect”. If the only breaking
>> change would be the package change, then there’s no sense to change the
>> name just to change the name.
>>
>>
>>
>> I think it is OK to change the Maven coordinates in any case. While it is
>> used sometimes as a starting point to look at a class and try to figure out
>> what library it comes from based on matching the package name to the group
>> ID, that’s not a common operation and modern IDEs (and search.maven.org)
>> can easily answer the question if needed. The only drawback to changing
>> Maven coordinates is it might make it harder for people to know there is a
>> newer package, that is, to search for upgrades we check for more recent
>> versions of current dependencies. However, with a project as big as Groovy
>> I think it will be clear when Groovy 3 comes out that users will know.
>>
>>
>>
>> Jason
>>
>>
>>
>> *From:* Keith Suderman [mailto:suder...@anc.org]
>> *Sent:* Monday, March 27, 2017 2:49 PM
>> *To:* users@groovy.apache.org
>> *Subject:* Re: Maven coordinates going forward
>>
>>
>>
>> +1 for changing Maven coordinates.
>>
>>
>>
>> -1 for changing package names.  Sure, new code can use the new package
>> names, but changing existing packages is just breaking changes for the sake
>> of breaking things with no real benefit.  I hope the Groovy team tries to
>> break as little as possible to avoid the "Python3 Effect", whether real or
>> imagined.
>>
>>
>>
>> Having said that, how much public facing code is in org.codehaus.groovy
>> packages?  I don't think I've typed "import org.codehaus.groovy..." in my
>> life, but IntelliJ may have inserted a few for me.
>>
>>
>>
>> Keith
>>
>>
>>
>>
>>
>> On Mar 27, 2017, at 2:20 PM, Jochen Theodorou  wrote:
>>
>>
>>
>> On 27.03.2017 20:08, Winnebeck, Jason wrote:
>>
>> The key thing in my mind is that you can't make a change that breaks
>> 100% of libraries at one time without fracturing the community or at
>> least introducing a major hindrance to upgrade that will mean
>> maintaining 2.x series for a very long time. Even if the upgrade
>> process is as easy as a recompile, there are a lot of published
>> libraries no longer maintained. Even for the ones that are
>> maintained, there are people who might not want to be forced to
>> upgrade every library. I'm not a Grails user, but my impression is
>> that the framework relies on a lot of plugins and is one of the (if
>> not the most) active Groovy communities and I have a hard time
>> envisioning how that upgrade path will take. You'd have to maintain
>> Groovy 2 and Groovy 3 versions of each plugin, and to upgrade you'd
>> have to upgrade everything at one time to the (most likely) latest
>> version.
>>
>> What is the possibility that the package names are changed, the
>> parser, metaprogramming model, etc. that all break in Groovy 3
>> change, but yet still have a compatibility JAR implementing the
>> minimal Groovy 2.x classes in a way that allows interoperability with
>> Groovy 3 code? Theoretically at a worst case, Groovy 3 should be able
>> to view Groovy 2 classes the same way as any other Java class. I
>> think many concerns would be lifted if Groovy 2 and 3 could co-exist
>> at the same time, allowing you to upgrade incrementally.
>>
>>
>> If you see the new metaprogramming model as chance, then it would make
>> sense to implement that in the new packages instead of transferring old and
>> to be deprecated classes. The goal would the to be able to run old and new
>> system at the same time, where the Groovy 1.x/2.x classes 

Re: @compileStatic and groovy.sql

[Wilson MacGyver]

I've been playing around with sql2o actually.

http://www.sql2o.org/

it has very good performance for read. https://github.com/aaberg/sql2o

and 99% of my SQL needs are read only.


On Fri, Jun 24, 2016 at 9:34 AM, Cédric Champeau <cedric.champ...@gmail.com>
wrote:

> For type safe sql those days I would recommend to use jOOQ.
> Le 23 juin 2016 06:58, "Wilson MacGyver" <wmacgy...@gmail.com> a écrit :
>
>> Ouch I will continue to embrace dynamic then :)
>>
>> On Wed, Jun 22, 2016 at 1:56 PM Guillaume Laforge <glafo...@gmail.com>
>> wrote:
>>
>>> Perhaps a custom type checker extension could be fed with the jdbc
>>> metadata...
>>> Le 22 juin 2016 7:41 PM, "Shil Sinha" <shil.si...@gmail.com> a écrit :
>>>
>>>> Hi Marc,
>>>>
>>>> You could use the map access syntax i.e. foo['id'] instead and
>>>> cast/coerce the result to the appropriate type.
>>>>
>>>> On Wed, Jun 22, 2016 at 1:37 PM Wilson MacGyver <wmacgy...@gmail.com>
>>>> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> If I want to use compileStatic with groovy.sql, how would I do that?
>>>>>
>>>>>
>>>>> the problem as far as I can tell is
>>>>>
>>>>> sql.eachRow("select id, from whatever") { foo ->
>>>>> ...
>>>>>   foo.id
>>>>> }
>>>>>
>>>>> returns data that is known at runtime
>>>>>
>>>>> but at compile time. there is no way to know that the SQL statement
>>>>> returns a
>>>>> id column.
>>>>>
>>>>> is there a way to do it?
>>>>>
>>>>> Thanks,
>>>>> Mac
>>>>>
>>>>> --
>>>>> Omnem crede diem tibi diluxisse supremum.
>>>>>
>>>>


-- 
Omnem crede diem tibi diluxisse supremum.

@compileStatic and groovy.sql

[Wilson MacGyver]

Hi,

If I want to use compileStatic with groovy.sql, how would I do that?


the problem as far as I can tell is

sql.eachRow("select id, from whatever") { foo ->
...
  foo.id
}

returns data that is known at runtime

but at compile time. there is no way to know that the SQL statement returns
a
id column.

is there a way to do it?

Thanks,
Mac

-- 
Omnem crede diem tibi diluxisse supremum.