Presenting GPetStore: a Groovy Pet Store application in a single script

I posted this on my company's blog, but basically, it's a script that I wrote that uses Groovy 1.6's Grape functionality to automatically pull down and tie together Jetty, HSQLDB, standalone GORM, and Spring in a single short groovy script that implements part of the JPetStore functionality.

Check it out.

Also, I created a quick Google project for it just in case anyone is interested in expanding it into a full fledged pet store implementation.

Getting out the Google App Engine Vote for Groovy

I might as well join in the fray of "getting out the vote" for Java/Groovy support in Google App Engine.

If you haven't heard, Google announced a new service: "Google App Engine". It's essentially a hosted application environment that roughly competes with Amazon's EC2 and S3 services. The initial release only supports applications written in Python. But Google has stated that they are looking into support for other languages.

So if you'd like to see Java/Groovy support in Google App Engine, you can vote for it by starring it here:
http://code.google.com/p/googleappengine/issues/list

Simple Java vs Groovy Perfomance Comparison

I recently read a post about doing comparisons with Groovy collections, and there was a snide comment that caught my eye:

Just write a simple helper. I guarantee that it will be 20 times faster than Groovy.

So I wrote some quick and dirty code to test exactly that. It's not scientific by any means, but my simple test showed that the Groovy version was about (edit: 7.5) times slower than the Java version.

That's still slow, but nowhere near as bad as the completely unsubstantiated claim of 20 times slower and not as bad as various other claims I've seen tossed around regarding the Java vs Groovy performance comparison.

And when you consider that Groovy is much younger than Java, that the JVM is only now starting to really get around to optimizations for languages other than Java, and that a main focus of the upcoming Groovy 1.6 release is performance improvements, that's really not bad at all.

For reference, here's the test code and the range of results for several runs. Again, it's a simple test and not scientific, but you can use it to get your own numbers. I'd love to see more people posting comparisons so that we can continue to make a factually based determination of where Groovy performance is slow.

Edit: I changed the Java version to a more compact form using Arrays.asList, increased the interations, and updated my performance numbers accordingly.

Groovy time: between 10781ms and 10688ms
Java time: between 1438ms and 1390ms
Java was roughly 7.5 times faster than Groovy (previous version was only 6 times faster)

GroovyListExamples.groovy:
-------------------------

class GroovyListExamples {

public List listSubtractionTest() {
 def smallList = [1,3,5]
 def bigList = [1,1,1,2,3,4,4,4,5,6,7,7,8,9]
 def result = bigList - smallList
}
}

JavaListExamples.java:
---------------------

import java.util.*;

public class JavaListExamples {

public List listSubtractionTest() {
 List smallList = Arrays.asList(new Object[] { 1, 3, 5});
 List bigList = Arrays.asList(new Object[] { 1,1,1,2,3,4,4,4,5,6,7,7,8,9 });
 return subtractList(bigList, smallList);
}

public List subtractList(List sourceList, List removeList) {
 Set removeSet = new HashSet();
 removeSet.addAll(removeList);

 List result = new ArrayList();
 for (Object item : sourceList) {
  if (!removeSet.contains(item)) {
   result.add(item);
  }
 }
 return result;
}
}

ListExamplesDriver.java:
-----------------------


public class ListExamplesDriver {
public static void main(String[] args) {
 GroovyListExamples groovyWay = new GroovyListExamples();
 JavaListExamples javaWay = new JavaListExamples();

 System.out.println("GROOVY:");
 System.out.println(groovyWay.listSubtractionTest());

 System.out.println("JAVA:");
 System.out.println(javaWay.listSubtractionTest());

 int NUMITERS = 1000000;
 long start, stop;

 start = System.currentTimeMillis();
 for (int i = 0; i < NUMITERS; i++) {
  groovyWay.listSubtractionTest();
 }
 stop = System.currentTimeMillis();
 System.out.println("GROOVY TIME: " + (stop - start) + "ms");

 start = System.currentTimeMillis();
 for (int i = 0; i < NUMITERS; i++) {
  javaWay.listSubtractionTest();
 }
 stop = System.currentTimeMillis();
 System.out.println("JAVA TIME: " + (stop - start) + "ms");
}
}

HTTP Traffic Monitoring and more with Charles

Just stumbled across this post discussing monitoring network traffic for Grails applications. It's not really Grails specific, but I was surprised that my favorite monitoring Swiss Army Knife, Charles, wasn't mentioned until the comments (though to be fair, it is a shareware product costing $50 after the trial).

If you haven't looked at Charles, and you do web development or testing, you should do so. It's basically a local proxy server that gives you a great set of tools for monitoring and manipulating how your applications communicate via HTTP (if you are behind another proxy server, no worries, Charles can delegate it's calls to that proxy server).

You can see the feature list here, but the highlights for me are request/response capturing (the core of the tool), bandwidth throttling (to test applications at various "internet" speeds), and new in the 3.2 release is breakpoint support. Breakpoints are AFAIK a unique feature to Charles and they allow you to "interactively change requests or responses as they pass through Charles".

I also use Charles for a non web development purpose on my laptop to simplify dealing with proxy settings. Basically, I point all applications on my machine to Charles (e.g. Firefox, IE, Eclipse, etc.) and then I just change Charles to enable/disable the use of an external proxy depending on where I'm connected.

Anyway, it's a very useful tool that is well worth checking out.

Sequence diagrams without wasting time in Visio

Just stumbled across websequencediagrams.com which lets you create UML sequence diagrams online without having to fire up Visio or your UML editor of choice. Not only that, but you actually generate them from text (it always seems that I end up wasting time fighting tools for these diagrams).

For example, here's the diagram created by this text:

   User->A: DoWork
  activate A
  A->B: <>
  activate B
  B->C: DoWork
   activate C
  C-->B: WorkDone
  destroy C
  B-->A: RequestCreated
  deactivate B
   A->User: Done

Pretty nice, and well worth checking out, especially if all you want is a quick diagram without wasting a lot of time.

Adventures in classpath scanning...

On a recent project I've run across a number of scenarios where I wanted to generically apply some logic across a large number of classes. Previously, I've done things like using Ant for this or used find and grep to create an input file with a list of matches and then writing code that read that file.

But what I really wanted was something much simpler that could easily be used in Java code without a lot of gymnastics. And Spring's ClassPathBeanDefinitionParser had almost everything I wanted, except that it was written specifically to generate Spring bean definitions and didn't expose the internal features that I wanted to use.

So I looked at the ClassPathBeanDefinitionParser source and wrote ClassPathScanner.java
(NOTE: It uses numerous Spring classes internally, so it requires Spring.)

It's a crude start, but the basic idea is there. And the results have been suprisingly easy to work with. For example, if you want to write a generic JUnit test that runs all of your tests:

public class AllTestsRecursively extends TestCase {
public static TestSuite suite() throws Exception {
    TestSuite suite = new TestSuite();
    ClassPathScanner scanner = new ClassPathScanner()
        .basePackage(AllTestsRecursively.class.getPackage().getName())
        .assignableFrom(TestCase.class)
        .includeFilter(".*Test");
    for (Class testClass : scanner.findClasses()) {
        suite.addTestSuite(testClass);
    }
    return suite;
}
}

Not rocket science, but it makes it pretty easy to write a lot of generic code. For example, you could use it to write tests that assert characteristics that might otherwise require aspects to enforce.

Or you could use it to dynamically generate Spring beans in ways not directly supported by ClassPathBeanDefintionScanner (e.g. you could search all of your services and create CXF bean definitions for all services that have the @WebService annotation).

I was surprised that something like this hadn't already been implemented in one of the Apache commons projects (or maybe it has and I just couldn't find it). But it seems like something that could be genuinely useful in many different scenarios.

Struts 1 Plugin for Grails

This one is hitting all of the Grails lists, but it's worth repeating. A Struts 1 plugin for Grails was just released.

Not only can you use this plugin to migrate your legacy Struts 1.x application by copying your config xml files, java files, and jsps into a Grails app. But you can also have your struts 1 actions use GSPs for rendering or even write your controller login in Grails controllers.

This is a shining example of how Grails' (and Groovy's) peaceful co-existence with Java can pay huge dividends.

So if you're stuck with a Struts 1.x app and desperately seeking a way to modernize your architecture, check it out yesterday.