GroovyVan.com // Vancouver Groovy/Grails UG

Welcome to the Vancouver Groovy/Grails User Group Q&A series. Today let’s welcome Vancouverite Ed Povazan.

Q: Can you tell us a little bit about yourself?

Ed Povazan: I’m a software developer living in Vancouver, BC. I’m a big Groovy fan, and will use the language almost anywhere, using Java as my ‘assembler’ in the few cases where high performance is required. I’ve been lucky to be able to take on contracts where I can use Groovy/Grails most of the time.

Q: How did you get started with Groovy? What makes Groovy your dynamic language of choice for Java applications?

Ed Povazan: I think it was sometime in 2003 that I discovered Groovy. I was looking for a language lighter on syntax than Java to use in my day trading tools. Groovy was still an early project by two guys, and not something I wanted to jump into yet. A little later on when a small community had grown around Groovy, I started using it in my day to day programming.

For me, using Groovy alongside Java is natural. Groovy is designed for the Java Virtual Machine (JVM). Groovy is the only alternate language for the JVM that integrates seamlessly with Java. Interfaces and classes are just that. You can define an interface in Groovy, implement it in Java, extend the Java implementation in Groovy, and so on. Once compiled, all you are dealing with is normal class files. Groovy and Java are languages for the JVM, as opposed to languages that simply run on the JVM.

To use and enjoy another language on the JVM, only to find out that you are limited in the ways you can use it with your existing code, is frustrating. When I used Jython a few years back, I loved it, but the harder I used it, the more I became exposed to its non JVM roots, like PyInteger, as well as the extra and unnatural effort required to be able to compile a class I could use in Java.

In addition, the learning curve with Groovy is as steep as you choose to set it. Much of the time you can simply rename a .java file with the .groovy extension – the Java syntax is mostly a subset of the Groovy syntax. The beauty of Groovy is when you start using Groovy specific features. What you end up with is far less code that clearly states its intent.

What more could I want – less code, clear code, less to maintain, easier to maintain – I am always pleasantly reminded of these facts when I delve into code that I have not seen in months. And tons of fun!

Q: Any comments on the state of the Eclipse Groovy plugin? Can you highlight some achievements and comment on what’s still missing in the Eclipse Groovy plugin?

Ed Povazan: The plugin provides a nice environment for editing, building and
testing Groovy code. There are some niceties such as code completion, JUnit integration and debugging. Developers on the Project Zero team (Aaron Tarter and Michael Fraenkel) have sorted out some difficult ClassLoader issues, amongst other things. This is really good news, as their changes solve other issues that a few users had been having. Their work was also a nice injection of activity, since the rest of the GroovyEclipse team has been very busy with other work, with little time time to volunteer to the project. Hopefully this will change soon. There is still much room for improvement. Better debugging support, adding code browsing, adding Grails specific features – all very nice to have in the future.

Q: Can you tell us some challenges you faced while working on the Eclipse Groovy plugin?

Ed Povazan: At first, when I started submitting small patches to the project, the code was packaged as one large plugin. Later on once I had become an official team member, I wanted to contribute with additional plugins. This was not easy, the original plugin was not designed for this. Luckily Jay Zimmerman of the No Fluff Just Stuff symposiums sponsored me to add code completion to the plugin. This gave me the chance to reconstruct the plugin into a set of plugins that more easily enabled new work to be done without affecting the one and only monolithic plugin. After which I worked on code completion for 5 weeks or so. It was really nice to work every day on this task, as opposed to the rather fractured focus that I had when working on the plugin in the odd spare ours.

Time is the biggest challenge for me – it is so easy to remain focused when working continuously, as opposed to working here and there in spare time. Productivity is higher, quality of code is higher, and it’s just more fun.

Thanks Ed Povazan. Check back next week discussing Grails – Groovy’s web framework – highlights coming up in the latest Groovy 1.1 release, tips on how to get started with Groovy and much more.

Interested in more? Join the discussion on the Vancouver Groovy/Grails User Group Forum/Mailing List.