What are /r/groovy's favorite Products & Services?

From 3.5 billion Reddit comments

I also prefer idea Intellij, for personal use the licence is $200(well worth it), but if you can hold out they usually have one really good sale once a year, where I picked up a copy for $50.

Other than that there is the Groovy/Grails Tool Suite, which is free and based on Eclipse http://spring.io/tools/ggts I've had mixed results with this in the past, but it's free, so at least worth a try.

Also don't for get you have grails console: http://grails.org/doc/2.0.2/ref/Command%20Line/console.html Which can be useful for debugging/playing with code, and looking at the code generated from an ast transform.

I don't think it's that complicated. There are some weird edge cases where Groovy is not Java, but 99% of the time "it just works".

This page on differences may help. I got bit by the inner classes differences once.

http://groovy-lang.org/objectorientation.html#_named_arguments

There is a little bit of documentation about the method argument features. Basically, default parameters should be defined last. There used to be a quip about Maps and named parameters in relation to ordering, but I think it was in an older version of the documentation. Here's the code I tried in a Groovy console that seemed to work. I had to remove the default parameter assignment to the Map, so I guess it's a special case for Closures.

def foo = { Map kwargs, ...args -> println "kwargs=${kwargs.toString()} args=${args.toString()}" }

foo(1:1, 2:2, 2, 3 ) > kwargs=[1:1, 2:2] args=[2, 3]

It got me to playing a little bit. Notice that explicitly defining a map argument caused varargs to contain the explicit map. Any "named parameters" were shuffled into the Map parameter instead of being assigned into the varargs parameter.

foo(2, 3, 4, [5:6], 7, 8:9) > kwargs=[8:9] args=[2, 3, 4, [5:6], 7]

Here are some hints:

1.) Use XmlSlurper to read in the HTML file. 2.) Select and replace the HTML tag using a GPath expression 3.) Celebrate!

It's dynamical by default. This includes a decision tree that may invoke plenty of different things, see http://groovy-lang.org/metaprogramming.html This led to many shortcuts, like X.a invoking X.getA(), but only if certain conditions are present. If you switch the given class or method to static compilation, this would behave quite differently. Then you have subtle differences to Java: http://stackoverflow.com/questions/687601/valid-java-code-that-is-not-valid-groovy-code/25974513#25974513 Finally Groovy has no finished specification, there are several corner cases where the behavior of Groovy does not follow any near-complete written specification, so it is difficult for maintainers to decide if some behavior is a bug or a feature (may be changed in the next release or not).

When Groovy features are used conservatively, none of this really matters, but when developers become more adventurous, this can become an issue.

This is exactly how and why I use @Delegate as often as I do.

Also, one of the most frequently quoted rules from Josh Bloch's Effective Java book is "Prefer composition to inheritance". There are a whole host of good reasons given there for preferring composition and @Delegate makes doing the right thing easy!

install grails-melody plugin

• First read docs on what it does
• Next let your slow code thing run for a bit.
• Last check dat data from melody it will tell you what is slow.

groovy docs are good. groovy in action 2nd edition is on the way.

for grails, grails reference docs are great. http://grails.org/doc/latest and peter ledbrook is also writing a new grails book for grails 2.0.

Not an Android Dev, but I do use Groovy daily. You’ll need the groovy runtime Jars which do take a few megs, but nothing terrible. You can also run groovy code dynamically and directly without a manual compile step: http://groovy-lang.org/integrating.html#integ-eval

You can evaluate groovy code loaded as a string dynamically at runtime. It also makes for a pretty good base to build a DSL.

No huge gotchas that I know of, performance is great in most cases and the ease of use and terseness is really nice. Being able to write and parse JSON without external libs is awesome, closures are way easier to work with than java 8, optional typing allows you to only worry about typing when you want to, it has mixins, and you can cast damn near everything, this is especially nice for implementing minimal parts of an interface.

It’s the basis for Spock unit testing which I believe android is already friendly with? So this might not be much of a lift. Good luck!

If you're running that in a groovy shell, then you have to use interpreterMode . Otherwise F will not be saved to the shell’s environment.

http://groovy-lang.org/groovysh.html#GroovyShell-Variables

http://groovy-lang.org/groovysh.html#GroovyShell-InterpreterMode

Okay, why are we saying Groovy is not funded by pivotal. I just visited their website and I see this: The Groovy programming language is supported by Pivotal and the Groovy community.

You can check out information about Kotlin's null safety here and the relevant part is really this line:

> In Kotlin, the type system distinguishes between references that can hold null (nullable references) and those that can not (non-null references).

That means the compiler will make you handle scenarios where your values could be null. You have to write your code so that it explicitly says you allow it to be null. You can still get NPE in Kotlin but it's usually because you're using Java code that returns null. This is a huge addition on top of ?..

Like these other guys have said, IDEA is a great product. Their free edition supports groovy too: https://www.jetbrains.com/idea/download/

It's not the quickest program to boot up, but honestly, if you're writing something longer than 10 lines, the gains of having an IDE are well worth it.

I second reading 'Clean Code'. I agree with most everything /u/g-money-cheats said, and to expand on the "structure of the code needs a lot of work", a great first step would be to extract smaller methods out of your getData method. You really want your methods to be as small as possible... just a few lines each ideally. Start with the bodies of those if/else blocks. This will decrease the cyclomatic complexity (level of indentation), divide it into more manageable chunks, and allow you to write meaningful method names for those chunks to make the code more comprehensible

I picked up this book and it was pretty easy to pick up if you're familiar with Ruby. It does a good job of going over the "java" aspects of groovy without going into too much detail. And its fun!

http://www.amazon.com/Grails-2-A-Quick-Start-Guide/dp/1937785777

Ack, I just realized that was Grails... but it was very fun and informative for me personally.