Guillaume Laforge | 20 May 02:26 2015

[groovy-user] [ANN] Groovy Weekly #70

Hi all,

It's already Wednesday here, but still Tuesday in Americas, so here's Groovy Weekly #70!

Keep on groovy-ing, and remember to subscribe to the new mailing-lists!

Guillaume Laforge
Groovy Project Manager
Product Ninja & Advocate at Restlet

Guillaume Laforge | 19 May 20:14 2015

[groovy-user] test, please ignore

Test to see if the Codehaus mailing-lists are already gone too.

Guillaume Laforge
Groovy Project Manager
Product Ninja & Advocate at Restlet

Guillaume Laforge | 14 May 22:56 2015

[groovy-user] [IMPORTANT] mailing-list moving to Apache

To all those still on these Codehaus-hosted Groovy mailing-lists.

A gentle reminder that in a few days, those lists will be decommissioned.

You really have to use the Apache mailing-lists now!!!


Guillaume Laforge
Groovy Project Manager
Product Ninja & Advocate at Restlet

Sergio Michels | 14 May 22:35 2015

[groovy-user] Extend JsonSlurper to dynamic parse dates?

I'm trying to use JsonSluper to parse a JSON that I'm not fully aware of the content. So the client may send me a date in a custom format, and I want to be able to parse it as a Date and not String.

{someField: '2015-05-14T00:00'} //need to produce a Date, but I don't know that someField contains it.

Is there a way to extend JsonSluper to be able to parse it? 

Here's some similar discussion:

Sérgio Michels
Guillaume Laforge | 12 May 03:30 2015

[groovy-user] [ANN] Groovy Weekly #69

Hi all,

A pretty early morning release of Groovy Weekly #69 this time!

Lots to read, as this is two weeks worth of items :-)

Please don't forget to subscribe to the new Groovy mailing-lists, and to update your bookmarks regarding our bug tracker, our new Github mirror, etc.

Keep on groovy-ing!

Guillaume Laforge
Groovy Project Manager
Product Ninja & Advocate at Restlet

bkarsh | 3 May 20:00 2015

[groovy-user] Best way to store/load/access configuration data for a groovy script?

Hi guys,

Hoping you can help me out. I am working on a project to map a bunch of data
from different fields into a new single field (a data normalization
project).  I plan to have a config file that has values like so:


(note that since everything ultimately maps to a single field, I am not
including the name of the mapped field in the config file)

I was thinking about slurping in the file, and converting it to a nested map
-- the below is pseudo-code-ish... and hasn't been checked for syntax:

def map = [ fieldName : [ fieldValue:mappedValue ] ]

The config file can contain an unknown number of fieldNames / fieldValues --
but the config file will always follow the
fieldName::fieldValue::mappedValue  format.  

I want to be able to directly access the key/values by first checking
fieldName -- then checking if fieldValue exists, and then providing hte
mapped value. 

Any tips? Also -- if there is a best practice on how to do this sort of
thing that is completely different than my approach, that's fine -- I'd
rather follow best practices than some silly approach.  For example, if it
is ass-backwards to convert a config file into a map like I propose, etc. I
do want the config file to be in a format tha t is easy for non-programmer
types to update. 

Thanks for any advice!

View this message in context:
Sent from the groovy - user mailing list archive at

To unsubscribe from this list, please visit:

Cédric Champeau | 27 Apr 17:40 2015

Re: [groovy-user] Why aren't more people looking at Groovy?

Sorry for not commenting directly on what you guys are talking about, but it would be better to bring that discussion to the new mailing list [1]. This one could be removed anytime from now.



On 04/27/2015 05:37 PM, Owen Rubel wrote:
I apologize but what attitude are you talking about? Was it me pointing out the misconception or that this was never an attempt to convert Scala developers.

If you saw attitude, it wasn't there.

On Mon, Apr 27, 2015 at 8:31 AM, Roberto Guerra <> wrote:
That kind of attitude will just push Groovy further and further out of wide adoption. These are valid reasons why other languages are chosen over Groovy, and it is coming from people that use or have used Groovy in production apps. 

And btw, Alessio wasn't the one to bring up Scala and Clojure. He merely corrected some misconceptions about Scala that were mentioned.

On Mon, Apr 27, 2015 at 9:22 AM, Owen Rubel <> wrote:
This was never a Scala discussion, Alessio. We don't want Scala developers to convert.

This was a discussion on why people don't see Groovy as an option. Re-read the thread.

On Mon, Apr 27, 2015 at 8:15 AM, Alessio Stalla <> wrote:
On Mon, Apr 27, 2015 at 4:59 PM, Owen Rubel <> wrote:
"However, for certain people functional implies Big Scary Static Type System"

See this is what I was saying before. I had this conversation in the Scala community and this was repeated over and over. I stated that you could use <at> CompileStatic and they said 'yeah but you have to DECLARE it'

I responded 'so you are faulting Groovy for being flexible? Your argument is Scala is better because it is inflexible?!!'

This is where people change the subject.

Certain folks are just scared by dynamic typing. Others (like me) are scared by too complex static typing. To everyone their tools... anyway, it's not a matter of <at> CompileStatic alone. Scala's type system is not only static, it is more complex (and more expressive) than Groovy's. You're not going to convince Scala developers to move to Groovy with arguments about the type system, because for them Scala's type system is an advantage over Groovy, the same as for some of us Groovy's is an advantage over Scala!

If anything, <at> CompileStatic is a sign of maturity. It means that the language is used in so many projects and scenarios that it must support both dynamic and static typing to a degree, although it will always prefer one over the other (you can't have everything!). It also means that its design is solid enough to allow both. <at> CompileStatic would not be possible in vanilla Ruby, Python, or JS. That's a subtle point worth mentioning.

-- Cédric Champeau Groovy language developer
Alex Jeannopoulos | 26 Apr 20:58 2015

[groovy-user] Embedded Groovy Issue

I am using groovy in an embedded fashion within a custom tcp server. We use groovy to be able to "patch" the system dynamically. We have event handlers to handle various tcp events. With out hotfix system, we load a groovy script using the following snippet. 

static GroovyClassLoader groovyClassLoader = new GroovyClassLoader();

        GroovyCodeSource gcs = new GroovyCodeSource(scriptFile);
        gcs.setCachable(false); //cache disabled
        Class<?> cmdClazz = groovyClassLoader.parseClass(gcs, false); //cache disabled

        object = (T) cmdClazz.newInstance();

Then we replace the old event handler with  the newly instantiated one from the GroovyClassLoader. This works very well. 

But if a handler script is created that references non existing methods in a class loaded by the system classloader, it will load a class and even create an instance of the class. Then when the new event handler is invoked, the invoked method will execute until the point of "bad reference" and then it will just stop invocation. There is no exception thrown or knowledge of why it stopped. 

We are using an older version of groovy 1.8.9, any thoughts of how I can validate the newly instantiated handler to ensure it will compile and execute correctly. Thanks 

Eric MacAdie | 26 Apr 17:19 2015

[groovy-user] Why aren't more people looking at Groovy?

In addition to Groovy, I am also interested in Clojure. I found an interesting article on the Clojure reddit: "Our curvy road to Clojure" at

The basic gist of the article is that they were a Java and Ruby shop, and they realized that combination was not working as well as they hoped, so they started looking for alternatives. They tried JRuby and Scala, before settling on Clojure.

What I find odd is he never mentions looking at Groovy.

I hear and read a lot about shops that start out using Java and pick up Ruby, and some of them eventually realize that the chocolate and the peanut butter do not mix as well as they had hoped. So they look for something else. Yet I never hear about any of them looking at Groovy. It seems like if you are using Java for heavy lifting and Ruby for more dynamic/agile work that Groovy would be a great fit.

Has anyone else noticed this? Any thoughts?

= Eric MacAdie

Guillaume Laforge | 22 Apr 00:50 2015

[groovy-user] [ANN] Groovy Weekly #67

Hi everybody,

The 67th edition of Groovy Weekly is out:

As I say again in introduction of this column, don't forget to subscribe to the new mailing-list, to note the new issue tracker URL, as well as the new location for the sources on Apache's Git and Github's mirror!

Guillaume Laforge
Groovy Project Manager
Product Ninja & Advocate at Restlet

jreyeshdez | 21 Apr 11:07 2015

[groovy-user] Remove duplications from list of lists


I was wondering how I can achieve the following result using the method

I have the following list:


And I would like to get the following:

[ [name1,1,1,1800],[name2,1,1,800],[name2,1,1,1800],[name1,1,1,800] ]

I tried to use: 

data.unique { a, b -> [a[0],a[3]] <=> [b[0],b[3]] }

But it does not work..

View this message in context:
Sent from the groovy - user mailing list archive at

To unsubscribe from this list, please visit: