At the last Hackergarten we came together and created two screencasts, both about projects in the Groovy ecosystem.

The first is about GroovyServ, an application that increases the startup time of Groovy scripts. It is in German, but is easy to follow along even if you don’t speak the language. You can vote for it at DZone here and watch it below:

The second is about CodeNarc, a static analysis tool for Groovy similar to FindBugs or PMD for Java. The screencast can be upvoted at DZone or watched below:

Be sure to follow the mailing list for future Hackergarten events… it would be great to have some more people come out and join us next time.

Groovy CodeNarc is a static analysis tool for the Groovy language and does for Groovy what PMD and FindBugs does for Java: it analyses Groovy code for defects, mistakes, and bad practices. The new version 0.11 is a huge release for us. We’ve added over 50 new rules to the product (bringing the total to 130+ rules) and a few really great features. This is THE new look CodeNarc, and it’s ready to use today in beta form using the CodeNarc Web Console with the release coming by Monday, and we’ll be updating the Grails, Gradle, and Griffon plugins shortly. This post explains a few of my favorite new rules and features, and explains how you can help out. You can play with all the new rules today in the CodeNarc Web Console, so if you find any rule misses, false positives, or just new ideas then save the script and drop us an email! So here is my list:

@SuppressWarnings Support
All rules now recognize the java.lang.SuppressWarnings annotation on fields, methods, and classes. If this annotation is added then there will be no violations produced. This is great for the times when you really do want to ignore a rule or in the rare case where you find a false positive. Just as in Java, the annotation requires a String or List parameter. For example, annotating a class with @SuppressWarnings(‘UnusedPrivateField’) will ignore the rule for that class. Annotating a method with @SuppressWarnings(['UnusedPrivateField', 'UnnecessaryIfStatementRule']) will ignore both rules for the annotated method.

New Rules: Should use Operator not Method Call
Groovy supports Operator Overloading. “a.plus(b)” should be written as “a + b”. Likewise “a.minus(b)” should be “a – b”. Every single operator overloading in Groovy is supported: And, or, CompareTo, GetAt, etc., etc. This is great for newcomers (and old-timers) who often revert back to the Java way of doing things without realizing it. Check out these rules in the basic ruleset of the CodeNarc docs for more information: ExplicitCallToAndMethod, ExplicitCallToCompareToMethod, ExplicitCallToDivMethod, ExplicitCallToEqualsMethod, ExplicitCallToGetAtMethod, ExplicitCallToLeftShiftMethod, ExplicitCallToMinusMethod, ExplicitCallToMultiplyMethod, ExplicitCallToModMethod, ExplicitCallToOrMethod, ExplicitCallToPlusMethod, ExplicitCallToPowerMethod, ExplicitCallToRightShiftMethod, and ExplicitCallToXorMethod,

New Rules: Explicit Creation of Collection Types
We all know the “[]” is an ArrayList and “[:]” is a HashMap. Do you know the syntax for Sets, HashSets, LinkedList, Stack, and TreeSet as well? CodeNarc does, and will tell you when you explicitly create an object of this type instead of using the Groovy shorthand. You’d be surprised how often it catches you out. Check out these rules in the basic ruleset of the CodeNarc docs for more information: ExplicitCreationOfArrayList, ExplicitCreationOfHashMap, ExplicitCreationOfHashSet, ExplicitCreationOfLinkedList, ExplicitCreationOfStack, and ExplicitCreationOfTreeSet

New Rules: Null Safety
Null stinks, don’t use it. Easier said then done and hand-rolling an option type will raise the eyebrow of even the most hardened Scalar. So here are some rules: if your method returns a collection or map, then never return null. Return an empty collection instead. It makes the calling code a lot prettier to not worry about the null checks. Likewise, don’t return null from Boolean methods or CatchBlocks. They are accidents waiting to happen. The cool thing about these rules is that they analyze methods and closures to infer return types. It doesn’t just look at the method signatures it discovers the return type using type inference. We’re trying to make this more powerful and have even swapped some ideas with the groovy++ guys to see what we can share. In the meantime, check out these rules: BooleanMethodReturnsNull, ReturnsNullInsteadOfEmptyArray, ReturnsNullInsteadOfEmptyCollection, and ReturnNullFromCatchBlock

New Rules: Useless Constructs and Dead Code
Code can appear after a return or throw statement, but you should probably delete it. The Dead Code Rule helps you here. But many other things are pointless as well, such as double negatives in boolean expressions (DoubleNegative Rule), supplying a default constructor as your only constructor (UnnecessaryConstructor Rule), various useless calls on collections like “x.containsAll(x)” (UselessCollectionCall Rule), overriding a method only to call super() as your single line implementation (UselessOverridingMethod Rule), and return keywords in general (UnnecessaryReturnKeyword Rule).

New Rules: JUnit Clarity Rules
xUnit Patterns is a great book, but who has time to read the 800 page tome? No worries, we mined the text for good Junit rules. Don’t bother reading, just configure CodeNarc to do the learning for you. The UseAssertEqualsInsteadOfAssertTrue makes sure you use assertEquals instead of assertTrue with an explicit .equals() invocation, and UseAssertTrueInsteadOfAssertEqualsRule does the opposite: use assertTrue instead of assertEquals(true, …). You can guess what the rules UseAssertNullInsteadOfAssertEquals and UseAssertSameInsteadOfAssertTrue do. Also, using the fail() method instead of fail(String) obscures test failures. UseFailWithMessageInsteadOfWithout makes sure you don’t use it. Lastly, you may want to abandon JUnit entirely and use Groovy Power Asserts. We have you covered with JUnitStyleAssertions.

New Rules: Naming and Inheritance Problems
Some simple rules… don’t name a class Exception if it doesn’t extend Exception (ConfusingClassNamedException Rule). Don’t name fields, methods, or closures with names that differ only in capitalization (ConfusingMethodName Rule), and make sure that methods subclassed off Object are spelled correctly (ObjectOverrideMisspelledMethodName Rule).

And many other rules:
OK, I don’t want to leave any out, so here are the other rules included in the release:
The DuplicateCaseStatement Rule check for duplicate case statements in a switch block, such as two equal integers or strings. The GStringAsMapKey Rule checks that GString are not used as a map key since its hashcode is not guaranteed to be stable. The InvertedIfElse Rule checks for an inverted if-else statement, which is where there is a single if statement with a single else branch and the boolean test of the if is negated. The SerialVersionUID Rule checks for a serialVersionUID field that is not long, static, and final. The RemoveAllOnSelf Rule checks that you don’t use removeAll to clear a collection which is unsafe.

The SynchronizedOnGetClass checks for synchronization on getClass() rather than class literal which is again unsafe. The UseOfNotifyMethod Rule Checks for code that calls notify() rather than notifyAll() which is also usually unsafe. And the CatchIllegalMonitorStateException Rule checks for catching IllegalMonitorStateException which is usually a sign of faulty multithreading and interruption logic.

The last few are MethodCount Rule which checks if the number of methods within a class exceeds the maximum (configurable), the DuplicateNumberLiteral Rule which checks for duplicate number literals within the current class, and the DuplicateStringLiteral Rule which checks for duplicate String literals within the current class.

If you turn on all of these rules I am sure you will have hundreds if not thousands of violations. That’s a good thing!

How to Help
Yes, we need your help. We want 50 more rules for the next release. Here’s some ideas to help for those without much time.
Got 2 Seconds? – Vote for the IntelliJ IDEA feature request to support CodeNarc in the IDE.
Got 1 Minute? – When you find a false positive then head to our Bug Tracker and enter a ticket.
Got 2 Minutes? – In your next code review write down one of the problems you found and the correct fix. Email it to me at hamletdrc@gmail.com or just save the script in the CodeNarc Web Console. I’ll create a rule for it. Could be a bug, an idiom, or just a preference.
Got 5 Minutes? – Take the issue from your code review and brainstorm some edge cases. Then head to our Bug Tracker and enter a ticket.
Got an Hour? – Write a rule. It’s simple and automated. Checkout the source, do a “mvn clean install” from the root, and run “groovy codenarc.groovy create-rule”. You’ll be prompted for input and the script creates everything you need, including failing unit tests. If you need help email the mailing lists.
Got Photoshop Skills? – Can you please make us a new logo? Pretty please?

Now go download those bits, run the reports, and see what you learn!

Recursive functions are so 2009. All the cool kids are now scrambling to convert those legacy recursive functions into stack based iteration. Why would you ever need this, you ask? Maybe you’ve heard of my friend “StackOverflowError”, he likes to hang out on the JVM. Or maybe you’re a browser kinda guy and you’ve seen your alert messages say “Stack Overflow”. Or worst case (like me), you’re supporting IE6 and you finally figured out that the “Browser shows a blank screen” defect you can’t reproduce is IE’s way of overflowing (oh yes it really is). Well, stack based iteration is a way to leave your nice recursive function the way it is, yet still avoid the overflow errors. You just have to keep track of the function stack frames yourself by adding a little boilerplate around your method (and even that can be cleaned up fairly easily).

So here is the tale of taking the road now commonly traveled. Learning to program imperatively, writing some beautiful recursive functions, and then ripping it out again because of platform limitations. There and Back Again – A Developer’s Tale of Recursion. The code below is Groovy, but could easily be most any popular language.

Let’s start at the beginning, with a simple function that reverses a string:

assert reverse('forward') == 'drawrof'

And the way most of us learned to write the function in the first place, using iteration and an imperative style:

String reverse(String source) {
    def dest = new StringBuffer()
    ((source.length() - 1)..0).each { i ->
        dest << source[i]
    }
    dest.toString()
}

If it weren’t for the curious popularity of printing out greetings to the console, this might very well be the canonical intro example in most text book. The code keeps a counter starting at the maximum offset of the string and steps backwards by one appending the offest byte of the string back into the StringBuffer. The dest variable is mutated every step of the way and hopefully ends up with the correct value.

Enter recursion. It’s new. It’s different. It’s so much simpler. Can I complete new tasks that I couldn’t before? No, but as Steve Yegge said, “There is in fact one thing you can do using recursion that you can’t do using iteration, namely: You can use it to weed out stupid fugging interview candidates.” Check out the new coolness:

String reverse(String source) {
    if (source.length() < 2) return source
    String lastChar = source[-1] 
    String allButLastChar = source[0..-2] 
    lastChar + reverse(allButLastChar)
}

It’s declarative. The reverse of a zero or one length string is itself. Otherwise it’s the last char plus the reverse() of the rest of the string. It’s immutable. There are no mutations anywhere in this code. It’s independent of types (even though I did specify the input and output types). And it’s beautiful in a way.

And it shouldn’t be used on the JVM and in any browser Javascript that I know of. Even for recursions of one or two, some versions of IE actually detect code that looks like this and preemptively throw an exception even when there is no real Stack Overflow error.

I’ve now had several occasions to have to revert recursive functions back to iteration (both my own code and that of others). You don’t have to go all the way back to step one. You can keep your algorithm and emulate stack frames yourself. It’s a basic recipe:
1. Create a Stack datatype to store method parameters (LinkedList works nicely)
2. Add the original method parameters to the stack
3. Create storage for your output (here a StringBuffer)
4. While the stack still has elements… pop the head off your stack and run your basic algorithm. Where recursion was needed, do not call yourself, instead just push the new parameters back onto the head of the stack so the next iteration will execute it. Your stack will grow and shrink as your algorithm runs, just like your call stack would have.

String reverse(String source) {

    def stack = [] as LinkedList 
    stack.push source
    def result = new StringBuffer()
    
    while (!stack.isEmpty()) {
        source = stack.pop()
        if (source.length() < 2) {
            result << source
        } else {
            result << source[-1] 
            stack.push source[0..-2] 
        }
    }
    result.toString()
}

Is this better than the original iterative version? Certainly not for this trivial example. The stack management obscures the simplicity and intent of the function. But maybe this approach is better for your complex example, where your algorithm really is expressed more clearly using recursion. And I believe that we could remove this boilerplate in Groovy with a little metaprogramming (a task for a different night).

And what do do when your method has multiple parameters? Just make the stack be a stack holding arrays, and each entry in the array is a parameter value. With Groovy and multiple assignments this is quite simple. Here is a cute little anagram finder that requires two parameters. See how they are pushed and popped in pairs:

List findAnagrams(String prefix, String word) {
    
    def stack = [] as LinkedList 
    stack.push([prefix, word])
    def result = []

    while (stack) {
        (prefix, word) = stack.pop()
        if(word.length() <= 1) {
            result.add(prefix + word)
        } else {
            (0..(word.length()-1)).each { i -> 
                String cur = word[i]
                String before = word.substring(0, i)
                String after = word.substring(i + 1)
                stack.push([prefix + cur, before + after])
            }
        }
    }
    result
}
assert findAnagrams('', 'cat') == ['tac', 'tca', 'atc', 'act', 'cta', 'cat']

So what’s it all come down to? What is the best way to write this code? The first iterative version is plain and boring, the recursive version is sexy but dangerous, and the stack version is too complex for such a simple task.

I submit that the code should be written like this:

String reverse(String source) {
    new StringBuffer(source).reverse().toString()
}

Effective Java Tip #47 – Know and use the libraries. Behold the wonders of the JDK.

Hmmm… I really need to mock out java.sql.ResultSet, I know I’ll just subclass it with a hand-rolled mock. Oh-no, the default implementation without method bodies is 650 lines of code long. WTF? Did you know there are 197 public methods on the java.sql.ResultSet interface? This is an absurdly large interface, possibly the largest in the JDK (if not drop a comment, I’d love to know what the largest is). The workaround is to throw one together in Mockito (or your mock framework of choice). My implementation turned out to be 21 lines of code long. Not bad at all. To do it I creatively used ArgumentCaptors, Answer objects, and anonymous inner classes to capture state. The samples below are in Java, but they would be a little nicer in Groovy.

Anyway, here is the API I wanted to end up with… specify a String List for the column names, and then give any number of Object Lists for the data.

ResultSet resultSet = makeResultSet(
    Arrays.asList("Id", "Name"  , "Birthday"     ), 
    Arrays.asList(  1 , "Hamlet", new Date(9999L)), 
    Arrays.asList(  2 , "Andres", new Date(8888L)), 
    Arrays.asList(  3 , "Dierk" , new Date(7777L))
); 

List<Person> result = mapper.toPerson(resultSet);
assertEquals(3, result.size());
... // assertions left to your imagination

As you can see, the makeResultSet method creates a ResultSet object. ResultSet is part Map implementation and part iterator. As a Map, you can ask things like getString(“columnName”) and get a String result for a named column. Tons of data types are supported. As an Iterator, you can call next() to advance the recordset cursor, which tells you if there is a next record and also allows you to access the next record’s contents. It’s a pretty stateful object.

So here is how I implemented it in Mockito. We’ll dissect it below.

private static ResultSet makeResultSet(
                                     final List<String> aColumns, 
                                     final List... rows) throws Exception {

    ResultSet result = Mockito.mock(ResultSet.class);
    final AtomicInteger currentIndex = new AtomicInteger(-1);

    Mockito.when(result.next()).thenAnswer(new Answer() {
        public Object answer(InvocationOnMock aInvocation) throws Throwable {
            return currentIndex.incrementAndGet() < rows.length;
        }
    });

    final ArgumentCaptor<String> argument = ArgumentCaptor.forClass(String.class);
    Answer rowLookupAnswer = new Answer() {
        public Object answer(InvocationOnMock aInvocation) throws Throwable {
            int rowIndex = currentIndex.get(); 
            int columnIndex = aColumns.indexOf(argument.getValue());
            return rows[currentIndex.get()].get(columnIndex);
        }
    };
    Mockito.when(result.getString(argument.capture())).thenAnswer(rowLookupAnswer);
    Mockito.when(result.getShort(argument.capture())).thenAnswer(rowLookupAnswer);
    Mockito.when(result.getDate(argument.capture())).thenAnswer(rowLookupAnswer);
    Mockito.when(result.getInt(argument.capture())).thenAnswer(rowLookupAnswer);
    Mockito.when(result.getTimestamp(argument.capture())).thenAnswer(rowLookupAnswer);
    return result;
}

The basic flow is, create the mock ResultSet, mock out the iteration/cursor functionality, then mock out the row/column lookup functionality. Let’s take it from top to bottom.

1. static – I make private methods static. Almost always. It makes refactoring and moving the method so simple. Plus, you can easily analyze the dependencies of the method. They are all right there in the parameter list, no syntax highlighter needed. Moving on…

2. varargs – In unit test helper methods I use varargs a lot. It makes a really nice API for creating data. And remember, varargs is just syntactic sugar for a Java Array. In this example, rows is an Array of Lists. In production code you’d always want to check this parameter for null.

3. final – The parameters are final because we’ll need to reference them from within anonymous inner classes.

4. AtomicInteger – The result set functions as a cursor so there is always a current record. We model this as an integer and the current record is just the index into the rows array. It’s Atomic and final so that we can reference and modify it from within the anonymous inner classes.

5. next() and Answer – The Mockito Answer interface is a high powered “thenReturn” statement. With “thenReturn” you can only return simple objects, with Answer you get to do the same with an anonymous inner class. Think of it as a “thenReturn” factory. Notice, next() returns false when the currentIndex advances beyond the end of the rows Array. And next() calls increment the index to advance the record pointer. When I say “capturing state”, the AtomicInteger is the state and it is captured within the Answer instance. It’s good to know the Atomic family of classes.

6. Captore and Answer for Row/Column Lookup – Now we combine an ArgumentCaptor and another Answer object to implement the getString/getInt/getX functionality. The ArgumentCaptor is an object used to capture parameters sent to methods. It can tell us whether “Birthday” or “Name” was passed to our method. It wraps around the parameter and allows you to call it back later. Again, we use an Answer, combined this time with the Captor to return a row/column value. Our rowIndex is just the currentIndex pointer, and the columnIndex is the index of the parameter name (“Birthday” or “Name”) within the column list. From here it is just a multidimensional “array” access to get our cell value. Woot.

7. when() and the rowLookupAnswer – the rowLookupAnswer can be reused for any datatype in the ResultSet. This isn’t a complete list but was everything I needed.

The Point?
Mock object frameworks are very much about creating objects without the usual constructors and concrete implementations. For my project, Mockito was insanely useful without even using the assertions and verifications that normally go with mocks. Maybe the code is a little complex, I admit, but at least it is short. And as long as you understand Captors and Answers then it really shouldn’t be a problem.

Happy Mocking!

Early this week I pestered Dierk Koenig into letting me ask him a few questions about Groovy past and present and the upcoming release of Groovy in Action 2nd Edition. If you aren’t aware already, Dierk is the author of Groovy in Action, a Canoo Fellow, and a Groovy, Grails and GPars committer.

Hamlet: The original Groovy in Action was published almost 4 years ago using (I believe) Groovy 1.0, and the 2nd Edition of the book is scheduled next year to coincide with the 1.8 release. What are the biggest productivity improvements between Groovy today and that of 4 years ago?

Dierk: Well, there are so many cool developments that I hardly now where to start, and in the end I will probably end up forgetting the most important one. Anyway, I will try.

One of the most important features is backward compatibility. I think the Groovy team has done a very good job in advancing the language without introducing breaking changes.

For me, it is often the small changes that make a big difference like “power assert“. A newcomer may dismiss this as a minor thing but it is of ubiquitous use, beside showing the language power of Groovy. I could mention many more improvements: the completion of the GDK, Mixins, more Metaprogramming options, command expressions, the Grape packaging system, and so on, but two features make the biggest difference in productivity for me: AST Transformations and IDE support.

AST Transformations use annotations to demarcate classes, methods, properties, and the likes in order to
achieve an enriched compilation. You want your class to be immutable? Simply give it the @Immutable annotation and you have all the goodness. There are endless possibilities with this approach and it comes without runtime costs!

IDE support has evolved far beyond what I ever thought possible for a dynamic language. Code completion for dynamically added methods? Yes, that’s possible! And even though the Groovy compiler has no need for type inference, the IDEs can give code completion on inferred types. Cross-language refactoring? Done. And the list goes on…

Hamlet: In 2007 Groovy won the JAX Innovation award. Is Groovy still a leader in JVM innovation?

Dierk: Looking into the roadmap for Java 7 and 8, it is pretty obvious that many developers have fallen in love with Groovy features and this forces Java to provide equivalents for at least a subset. Groovy has become and still is a pioneer for Java language features, simply because we strive for language features that make us more productive while keeping the solution Java-friendly.

Hamlet: James Gosling wrote a famous paper called “The Feel of Java” in which he described Java not in terms of language features but in terms of a general mindset and philosophy. You’ve been involved with Groovy since almost the beginning. What is the “Feel of Groovy” and has it changed in the 7 years the language has been alive?

Dierk: There are two sides to this: the user view and the developer view.

As a user of the Groovy language, I would say that Groovy still feels as groovy as in the early days. The important points are:
- Groovy is dynamic (that’s the nature)
- Groovy is feature-rich (that’s where the fun comes from)
- Groovy is Java-friendly (hence easy to use)
Groovy always was and still is a “getting things done” language. It is pragmatic – as opposed to being dogmatic about language design theory.

For a developer, the feel of Groovy has changed. The early days were a bit of a wild-west but since version 1.0 (and not coincidentally the release of Groovy in Action) we feel a high obligation to evolve the language in a controlled fashion. In my perception, Groovy has become the de-facto industry standard for dynamic programming on the JVM and many projects and organisations rely on it.

Hamlet: Lastly, I see that readers can already download parts of Groovy in Action 2nd Edition from Manning’s MEAP program. Is the MEAP complete enough to be useful today or Groovy newcomers stick to reading the 1st edition for now?

Dierk: The first edition is still fully valid and for the sake of completeness I would advice newcomers to go with it. You can always buy the second edition later. Honestly, computer books are ridiculously cheap, especially if you compare it against the price-tag for the invested reading time (not even mentioning the invested writing time).

Hamlet: Thanks Dierk!

Dierk: My pleasure!

You can catch Dierk at the upcoming W-JAX conference this November in Münich. He will talk about parallel processing with Groovy, advantages and limitations of dynamic programming as well as about the Canoo RIA Suite.