This article originally appeared in the June 2010 edition of GroovyMag, the Groovy and Grails magazine. Parts 4 and 5 are currently available for download from the magazine’s site, and more will come each month. Enjoy!

The Groovy Programming Language advertises itself as an “agile and dynamic Language for the JVM”, but what does this mean exactly? This series of articles explains Lean Software Development, and shows how your choice of programming language can make your entire process remain nimble and adaptive. Each months article will cover one of the seven Lean Software Development principles and explain how Groovy and the associated ecosystem help eliminate waste, defer commitment, and build quality into your product.

About this Series
Groovy is an agile programming language. In order to explain what this means, these articles are structured around the seven principles of Lean Software Development. The previous installments included a short introduction to Lean, explained how an expressive language can eliminate waste in unit testing, and showed how the easyb Behavior Driven Development framework and Groovy Builders can build quality into your life-cycle. In later months we’ll explore how a dynamic language lets you minimize coupling and defer commitment, and how metaprogamming allows you to deliver fast. You’ll see how Groovy’s Grapes module system, alongside modules like Groovy Web Services, streamline interactions between development and other groups like operations and QA (an important aspect of respecting people). Finally, we’ll look at optimizing the whole by applying Groovy to domains that cross department boundaries: how Gradle improves the build process and easyb serves as a collaboration mechanism between different organization roles. The series will end with a discussion on the best practices of mixing Java and Groovy.

Some of the code examples are basic while others are advanced. The articles explore why the features of Groovy are important rather than the mechanics of any one Groovy feature. Hopefully you’ll leave with some new ideas about how to use Groovy, how to convince your team that Groovy is worthwhile, or most importantly, how to increase your productivity.

Lean Revisited
Part 1 of this series contained a more indepth explanation of Lean, and I won’t repeat it here. But as a quick refresher here are the 7 lean principles along with a summary for those principles covered previously:
1. Eliminate Waste – Reduce work in progress and half done work
2. Build Quality In – Instead of settling for finding defects, optimize your process to create fewer defects
3. Create Knowledge
4. Defer commitment
5. Deliver Fast
6. Respect People
7. Optimize the Whole

Principle 3 – Create Knowledge

I prefer the term “Software Engineer” to “Programmer” because it evokes a sense of professionalism, adherence to standards, and attention to quality that sometimes seems lacking in our industry. But “Engineer” also carries negative connotations when applied to software. As my co-worker Mike Mannion says, “Software development has less to do with conveyor-belt-fabrication (the image unfortunately most likely to be to be conjured up when we use the word engineering) than knowledge acquisition.” Indeed, Software development is a knowledge creating process. The mostbasic thing we do in our jobs is to discover what needs to be done in order to delight our customers. In fact, your product will benefit by finding ways to speed up this knowledge acquisition. Specifically, Lean provides two practices for this: short, frequent learning cycles and delayed commitment. Delayed commitment, postponing decisions until the last responsible moment, is covered in next month’s article. Today we’ll focus on shorting learning cycles.

So where does all this created knowledge reside? Large requirements and specification documents are enticing because they provide a wonderful illusion of certainty. They can be agreed upon in meetings, verified with checklists, cross referenced with traceability matrices, and then enforced by lawyers and courts when projects fail. Great software has as much to do with rock solid documentation as a great marriage has to do with a rock solid prenuptial agreement. No thanks, I say.

The software industry has clearly turned towards executable solutions for knowledge creation and retention, any plausible description for a marriage related “executable solution” leaves me feeling quite uneasy. Executable acceptance test frameworks abound: Fit, Fitnesse, and easyb, and new unit test frameworks appear every few weeks. The code you write, and the tests that accompany it are the most basic persistent form of system knowledge, and it is important that this knowledge be verified in an automated way.

The problem with traditional unit tests is that the test framework imposes so many particularities that the important knowledge of how your system must behave gets lost in a noise of subclassing, type definitions, and annotations. Wiki and spreadsheet based solutions like Fitnesse are a nice idea in theory, but I have not yet found customers willing to edit test data directly. Instead it is left to the developer to do it. To make traditional unit testing more friendly, some developers try to cut through this noise by using strange naming conventions and commenting their tests with standard comments, as in Listing 1.

public void test_users_can_be_retrieved() {
    // arrange
    ...
    // act
    ...
    // assert
    ...
}

I’ve found word separating underscores in method names to bring no real value. You’re going to have to press the shift key one way or another, whether it be with underscores or camel case. The practice I do like is the arrange-act-assert pattern. This pattern originated with William Wake as a way to add clarifying structure to unit tests. The idea is to codify and standardize the way tests are written: First arrange all necessary preconditions and inputs, then act on the object or method under test, and finally assert that the expected results have occurred. Tests are easier to read because the setup and verification phase is clearly separated from the block exercising the system under test, and test smells like a too busy act phase or missing assert blocks rise quickly to the surface.

Encoding your tests with comments is an interesting idea, but in the end comments are not executed, grow stale, and become misleading. A better choice than using comments is to pick a testing framework that eliminates all this noise, one that natively supports the structure of unit tests. A testing framework like Spock.

Spock is an innovative framework, taking new directions on fixture setup, mocking, and data driven tests. The goal of Spock is to allow the developer to focus solely on the input and output of tests and then get out of the way. One type of test available in Spock is the data driven test, seen in Listing 2.

def """does the user service contain
        a known set of users?"""() {
    setup:
        def service = new UserService()
    expect:
        def user = service.get(username)
        user.firstName == firstname
        user.lastName == lastname
        user.id == userID
    where:
        username << ['user1', 'user2', 'user3']
        firstname << ['John', 'Jane', 'John']
        lastname << ['Doe', 'Doe', 'Smith']
        userID << [123456, 654321, 789987]
}

Did you know that question marks and new line characters in methods names, like in Listing 2, are completely legal on the JVM? The Java language just doesn’t allow you to use them! While this is far from the main productivity boost from Spock, it does lead to some very nice looking JUnit reports. Figure 1 is our actual JUnit report from my current project. Seeing a space separated test name sure beats deciphering a camel case or underscore laden test name.

The value of Spock being built on top of JUnit should be obvious: your reports, builds, IDEs, and other tools continue to work as before. To the tools, Spock is just another unit test.

There are more interesting questions to ask about Listing 2, however. Reading the listing from top to bottom may be confusing. Are those “==” statements assertions, and how can they be made before the variables have been initialized? What does this test do exactly?

Spock shows the great power available behind Groovy. Those goto labels (setup, expect, and where) are some of the meaningful tags you are allowed to use within Spock, and these tags are enforced within the compiler. They are not goto labels at all but a vital part of a Spock test specification. Just as test fixtures can have setup and cleanup phases, so can individual test methods. Spock supports this idea natively at the compiler level. In-line comments and funny method names are replaced by first class support for testing.

Within the expect: phase, the statements including == are indeed assertions. You may write out the assert keyword longhand if you desire, but the point of an expect: block is to run assertions, so Spock lets you drop out this bit of ceremony from your tests.

Another surprising feature is that the expect block will be executed three times in this test: one time for each row in the dataset. So the first execution is with data user1, John, Doe, and 123456, the second execution receives the second “column” of the dataset and so on. Once you are used to Spock, the data tends to be read in vertical columns, since each column is input to the expect block. For testers weaned on JUnit the test might seem backwards, raising questions like “Why is the data the last piece of the test, shouldn’t that come first?” The short answer is, not if you want to create knowledge about your system. The important part of the system is how it behaves, how the UserService retrieves users. This information is front and center communicating to any future programmers on the project. The data that ensures this behavior comes later, and is usually less important than the assertions. The Arrange, Act, Assert pattern is required in imperative, sequential programming. Luckily, a strong language and an innovative framework let you focus more on knowledge creation than satisfying the semantics of your chosen compiler.

Data driven tests are just one of the options in Spock specifications. As you explore Spock you’ll find many of the BDD concepts available to use, as well as a unique solution to working effectively with mocking frameworks. Spock is built on JUnit, so it works without effort for popular build tools and IDEs, and the online documentation is superb (how often can you say that about an open source framework?). If you want to take tests as a form of knowledge creation, then Spock is definitely worth investigating.

The new 0.4 release of Spock contains another option for data driven tests as well: the data table. Previously, Listing 2 showed how lists can be used within Spock so that assertion blocks are automatically called several times with different data. The downside is that I sometimes find myself tilting my head as I try to read the vertical columns embedded in the lists. Similar to the data tables features in Scala’s Specs framework, Spock now allows you to embed pipe delimited data tables in your tests. Listing 3 is the same test as in Listing 2 but uses data tables instead of the Spock data
driven format.

def """does the user service contain
        a known set of users?"""() {
    setup:
        def service = new UserService()
    expect:
        def user = service.get(username)
        user.firstName == fname
        user.lastName == lname
        user.id == id
    where:
        username| fname | lname | id
        'user1' |'John' | 'Doe' | 123456
        'user2' | 'Jane'| 'Doe' | 654321
        'user3' |'John' | 'Smith'| 789987
}

The result is a much more readable dataset, neatly divided into rows and columns.

The test driven community has a great interest in improving the framework landscape. Unit tests have been heralded in the past as a way to capture information about the system being developed, but the JUnit and Java syntax combine to under-deliver on this promise. Finally, with both the Groovy language and frameworks like Spock, we are seeing unit tests come into their own in their ability to capture, express, and execute the workings of the system.

Sidebar: Expressive vs. Terse
I’ve been very careful to call Groovy expressive instead of terse, which are two different things. Terse means showing less. Terse can mean anything from an abstraction to an abbreviation. Court stenography or writing shorthand is terse. All of the information is captured, but in as small amount of space as possible. And practically no one except the original author can make sense of it. Perl and regular expressions are terse.

Expressive is also about showing less, but expressive specifically means showing less of the inconsequential and more of the consequential. If something is important, then an expressive language shows it to you. If something isn’t important, then an expressive language should hide that detail.

Being expressive is an important part of staying DRY (Do Not Repeat Yourself). Everyone knows that DRY mandates that you do not say things twice: there should be a single source of knowledge for any fact. Hiding information, and terseness, often violates this. An expressive language helps you stay DRY by making sure knowledge is embedded in the system once without a lot of extra noise. Simple terseness and hiding information might leave you with zero sources of knowledge! Not a good place to be. Strive for expressive, and be wary of terse.

Next Steps
An important part of creating knowledge is maintaining a culture of constant improvement: every team can benefit from a feedback cycle where you experiment with a new practice, reflect and learn from the experience, and then accept or reject the practice as part of your team culture. The annual, year end reviews common in many companies are the antithesis of this. They are self-improvement theater, where feedback comes months after events occur and the details of how to improve are lost behind closed door meetings, never to be heard from again. As an alternative, think short term. Treat each two week iteration as a chance to conduct an experiment. Try Spock for two weeks and then discuss the results as part of your iteration close. If the team doesn’t like it then stop using it and try easyb for two weeks.

If that doesn’t work then try something else. A two week commitment is much easier to sell to your teammates than a long term framework decision, and two weeks shouldn’t be long enough for even the worst decisions to irreparably harm a project. Week by week your team will improve as some of the experiments work and others fail. Just remember, an experiment or new practice should try to solve a specific problem for your team.

Next Month: Defer Commitment
Deferring commitment is about your keeping options open. It may seem wise to make decisions early, and it does lead to the illusion of progress. But decisions can be costly to unmake, and oftentimes new information will become available that affects the choices you’re willing to make. Next month’s article explores how Groovy and dynamic languages allow you to make decisions when you are ready, investigating ways in which you can use Groovy’s optional typing to your advantage.

Learn More
Spock is available through Maven and Google Code at http://code.google.com/p/spock/. The web has some nice Spock tutorials, the project lead has a blog at http://pniederw.wordpress.com/ and Parleys.com has a great 20 minute presentation from the 2009 Devoxx conference available to subscribers. For more information on the very cool mock objects available then you may wish to read my own post on the topic: http://canoo.com/blog/2010/04/20/spock-and-test-spies-a-logical-choice/ For books on agility, I still contend these three cannot be beat:

This year’s JAX.de conference hosted many great Java thought leaders, including one of my personal favorites Gilad Bracha. If anyone has the authority to critique Java and the Java platform then surely it is Gilad who spent years working for Sun on the language and platform tools. If you haven’t followed him recently, I recommend reading his papers on Pluggable Type Systems and Objects as Software Services. Lucky for me, my “Code Generation on the JVM” talk was sandwiched between his “Java: A Post Mortem” and “Newspeak: A Principled, Dynamic Language”. It was surreal to see my name next to someone I’ve revered for many years, and I felt a bit like the rookie professional athlete who has to play his first game against someone they grew up watching on TV.

As expected, his talks were good mix of humor, strong opinion, and thoughtful analysis. Here are my favorite bits:

If you can’t abstract over it then it doesn’t belong there.
An original sin of Java was constructors. They are static methods that commit to returning a concrete implementation. Remember the design mandate “program to interfaces”? Constuctors subvert this and gave rise to a cottage industry of Dependency Injection frameworks to get around the issue (as long as you consider VMWare a cottage industry!). You wouldn’t need DI if your language supported proper inversion of control in the first place. The next generation of languages hopefully won’t have this limitation.

Class initialization is absurd. There should be none.
Static state is bad, bad, bad and read Gilad’s great blog post if you aren’t persuaded. Without static state there is no need for class initialization. We’ve all heard that the JVM start up times are slow, but that is a bit of a myth. The problem is that through class initialization we’re asking the JVM to do millions of operations that could be avoided without static state. A Lambourgini isn’t slow, but it sure seems that way if you try to drive it to the Moon. Likewise the JVM.

Why should a high level language need a memory model in the first place?
The original Java memory model was incoherent, the revised memory model is understood by only five people in the world, and the actors for concurrency idea existed since the Gulati paper of 1970. Bracha’s point wasn’t that we need a better Java memory model, it is that we should have made a language that did not need to expose a memory model to the developers. As with many of the Java original sins, Threads were the wrong level of abstraction and something better like Actors should have been chosen.

Java is going to stay but it is going to stay where you don’t want to look
Everyone wants to predict the demise of Java, don’t they? But few people offer a real, long-term alternative. There is enough risk with any of the other JVM languages to persude Enterprises that sticking with Java is the best choice. The evening’s speaker panel agreed (mostly) that the real successor to Java didn’t exist today. So where will the next big lanugage come from? Who can monetize a programming language? Microsoft has somehow done it with .NET, but show me the Oracle business plan that details how to get rich from writing a programming language. Or any other company for that matter. Here is my prediction: all this language innovation results in the best ideas making it into libraries and frameworks available for the Java language, and Java remains number one on our beloved TIOBE index, clunky syntax and all.

Webapps make you reboot. It is called “session expired”
Newspeak was funded to solve the problem of always on, always updated software. Quick question: what version of Google do you use? I’ve never in my life seen a version number at Google.com and that is a deployment success story. All software should work this way. I’m unclear how Newspeak is going to solve the session state problem but I’m also certain that I do <i>not</i> fully grasp the Newspeak vision.

If you want a static language you should look at Egyptian heiroglyphics because it hasn’t changed in a long time
And another quote from Brian Hurt: “Demand that you not have to learn something new to learn new languages, and then wonder why languages don’t improve much”. Newspeak is a bold change, and people are going to be very resistent. Incremental changes like Groovy are much easier to sell than big sweeping language changes. And an always changing language can hardly be adopted by the masses. I left the session wondering if Newspeak is an experiment meant to fuel language innovation or a real alternative as a mainstream programming language.

Complicated is not a sign that you’re clever. It is a sign that you failed.
Simple solutions can be achieved with a low number of non-overlapping concepts. If you need something more complicated then build it by composing the simpler pieces together. Special cases like primitive types are the road to ruin. Or the road to massive popularity and success as is the case with Java. In my humble opinion: success is an accident, much better to aim for happiness.

Language development has moved away from professional language writer and into the hands of hobbiest developers
As a hobbiest developer working on the Groovy language, I have averaged a mere 2-3 hours a week of work over the last 12 months. The good news: I’m clearing my schedule after the GR8 Conference to work on Groovy’s GEP-4. The bad news, I am and will remain a non-professional hobbiest developer hacking on a language in my spare time. Life couldn’t be better.

A few weeks ago on a Friday evening, Canoo opened its doors to the public and hosted a new programming user group called Hackergarten. The goal of the group is different from other user groups: instead of learning from listening to a presentation they want to learn by writing code. In their own words:

Our goal is to create something that others can use; whether it be working software, improved documentation, or better educational materials. Our intent is to end each meeting with a patch or similar contribution submitted to an open and public project.

We’re excited to say that their contribution to the Gradle build system was accepted last week! The next release of Gradle 0.9 contains an “Announce” plugin that can notify you and your customers of build events using Twitter, Snarl, or the Ubuntu notification system. You can notify yourself of local build failures or notify your customers of successful formal build releases. It was a long Friday night, but the group of over 10 developers are all happy to see their work accepted. As the group sponsor, Canoo is happy to have kept them caffeinated and well fed.

The next Hackergarten is this Friday, 30 April 2010. The group plans to write some Griffon plugins, a desktop application framework written in Java and Groovy. The Griffon Project Lead (and Canoo employee)Andres Almiray will be present to help guide the group. If you are anywhere near the Basel area this Friday, then please stop by Canoo and come join the fun. Don’t worry if you’ve never seen Groovy or Griffon before, the point is to learn new skills and meet new people.

You can find out more information on the Hackergarten mailing list or follow @Hackergarten to stay up to date.

Come join the fun. Here’s what people are saying about the last event:

.

The first Hackergarten was a great event, not only because there was free pizza, but primarily because it was a true team event with everyone actively contributing. Submitting a patch for a new Gradle plugin at the end of the night was our goal which we reached successfully. I look forward to learning more about Griffon at the next Hackergarten.

Etienne Stuber

.

I learned how easy and powerful Gradle is. The fact: with a little group and in a little time, we wrote a worth-making contribution to an open source project. Did I have fun? Definitely, it was like meeting with friends but for a beer but enjoying coding at the same time. In the future I am interested in writing Grails or Griffon plugins.

Alberto Mijares

.

At Hackergarten I learned about the Pomodoro technique and how to use groovy closures to do exception handling in a smart way. And yes, I had a lot of fun! For future events I am interested in anything with new technologies but especially with testing different approaches on how to program in teams.

Christoph Sperle

Here at Canoo many of us are preparing to spend the next three days in the Alps at a bi-annual retreat called “Code Camp”, where we stay up all night hacking with technologies and on projects that don’t always fit within our normal projects. This is my first time going, but I hear from the old timers that it is three days of a Spartan like existence focused on replacing sleep with marathon coding sessions, and where anyone causing a build failure is kicked into the Well of Souls with a scream of “FOR SPARTA!”. I am… nervous.

Those who know me should not be surprised at my technology stack: Groovy for the language, Gradle for the build, and Spock for the unit tests. In preparation for the big event, I dropped Spock into our project, converted all the unit tests to Spock specifications, and then converted all the hand rolled mocks to Spock Interactions. (Why these aren’t called “Spock Mocks” or simply “Smocks” I do not know).

First Reactions
First, the Spock framework does some crazy language tricks that aren’t supported in Java or Groovy… and it does so in a statically typed way. Almost all my mocking code has the same IDE completion and navigation the Java solutions have. Pretty amazing stuff given the level of metaprogramming that is going on in the implementation. Optional static typing in Groovy is a very important feature, especially for tool support.

Secondly, did you know the JVM supports long, punctuated, multi-line method names? Check out this example:

class Whoa extends spock.lang.Specification {
  def """Did you know that the JVM
      allows really long method names
      that span multiple lines and
      contain punctuation?"""() {
 
    expect:
    your_mind_is_blown
  
    where:
    your_mind_is_blown = true
  }
}    

Spying
I wrote a post many moons ago about the difference between stubs, spies, and mocks. Spying on indirect output of a test is much more important to me than full blown mocking, and I feel extensive mocking is a design smell. So far, I’ve been impressed with the Spock’s ability to analyze test objects after the fact to determine what was and was not called on them. For instance, here is a simple Spock spec asserting that the mouseClicked was indeed called once:

def "Simple Spy Method"() {

    setup:
    MouseListener listener = Mock()

    when:
    listener.mouseClicked MOUSE_EVENT_1

    then:
    1 * listener.mouseClicked(MOUSE_EVENT_1) // once
}

The assertion line reads in English, “expect one time that mouseClicked was invoked”. If mouseClicked is not called by the test then the test fails. If mouseClicked is called more then once then the test failes. If it is called with the wrong parameter… yes, it fails. Any number is supported, not just one, and ranges are supported as well in the same syntax:

3 * listener.mouseClicked(MOUSE_EVENT_1)  // exactly 3 times
(2.._) * listener.mouseClicked(_)         // at least n times
(_..3) * listener.mouseExited(_)          // at most n times

0 * listener./mouse(Pressed|Released)/(_)  // never with regex

Method Constraints
Spock reinvents Matchers, doing away with the verbose syntax. The previous examples used equality in the matches:

1 * listener.mouseClicked(MOUSE_EVENT_1)

1 * listener.mouseEntered(_)

1 * listener.mousePressed(_ as MouseEvent)

1 * listener.mouseReleased( { it.source.getClass() == JLabel } ) 

1 * listener.mouseExited(!null) 
1 * listener.mouseClicked(!MOUSE_EVENT_3) 

Target Constraints
Matchers, or constraints, aren’t just for parameters in Spock. I have never seen this before, but you can add an expectation on the left hand side of mocks, not just the right hand side. In effect, there is a way to say, “expect that method X was invoked on any of my mock objects in scope, I don’t care which one”. In this example, there are 2 mouse listeners in scope, and mouseClicked is randomly invoked on only one of them. The assertion makes sure that at least one was invoked:

def "Target constraint Example"() {

    setup:
    def listeners = [Mock(MouseListener), Mock(MouseListener)]

    when:
    def x = new Random().nextInt()
    listeners[x % 2].mouseClicked MOUSE_EVENT_1

    then:
    1 * _.mouseClicked(_)
}

Failures Accumulate

One last point to mention… failures in expectations accumulate. No exception is thrown until the end of the method, at which point all failures are reported in a batch. For instance, assume that the following expectations are run, and all of them fail:

then:
2 * listener.mouseClicked(_)
3 * listener.mouseClicked(_)
4 * listener.mouseClicked(_)

Too few invocations for:

2 * listener.mouseClicked(_)   (1 invocation)
3 * listener.mouseClicked(_)   (0 invocations)
4 * listener.mouseClicked(_)   (0 invocations)

Great stuff. You can try out Spock in the SpockConsole, and you can see some photos from out last Code Camp on Flickr. And watch this space for future posts after we are all finished. Thanks!

Canoo Software Engineer Hamlet D’Arcy was interviewed for the GR8 conference about his professional background and his conference contribution as well as Groovy and the Canoo Hackergarten.

Here’s the link to the interview! And here are some pictures of Hamlet during Canoo Day 2010:

Enjoy a new video of Canoo Fellow Dierk König in action:

"Scala, Groovy, JRuby, Clojure - Which JVM language is for you?"

In this discussion, panel members Dierk König, Guillaume Laforge (Groovy), Charles Nutter (JRuby), Stefan Tilkov (Clojure) and Ted Neward (Scala) discuss with the audience the pros and cons of the popular JVM-based lanauges Scala, Groovy, JRuby and Clojure in order to attempt to reach a verdict of rank. The panellists try to logically wade through arguments based on the key concepts of each language along with their primary applications and try to resolve clichéd comparisons such as performance.

JAXenter interviewed Canoo Fellow Dierk König on Groovy++. Read the Interview in German or join the Groovy++ Group dedicated to discussions of experimental statically typed compiler for Groovy programming language!

Update: As from now, the interview is also available in English! By the way: What is “Groovy++”?

Dierk König: Groovy + + is an extension of Groovy, which makes Groovy code pretty much as fast as native Java. In addition, you get static type checking plus type inference, yielding the benefits of compile-time safety but without the noise. To use the language extension, you only need one additional jar file in the classpath. Then you can annotate the required code parts – classes for example – with @Typed. The rest happens automatically. This approach takes advantage of Groovy’s ability to hook into the compilation step with AST Transformations. The name “Groovy + +” indicates that it is still Groovy, and therefore encompasses the entire beauty of the language syntax while exceeding the standard characteristics. Read on!

Watch an interesting interview (in German) with Dierk König about the actual language diversity in the Java community — Groovy, Scala, Clojure, JRuby and all the rest of them! If you are interested in this topic, we also recommend to take a look on the schedule of the Java Language Days 2010 (moderated by Dierk König and Markus Völter (itemis).

Recently, Dustin Marx postet his top ten of the most “Software Development Developments of 2009“. Here is a short summary as a basis for further discussion:

Changing Landscape of Software Development Conferences: Colorado Software Summit and SDWest and SD Best Practices terminated their long-running tradition in 2009. There is speculation that JavaOne 2009 may have been the last.

Java IDE Wars: IntelliJ IDEA has been the only one of the four leading Java IDEs that has not been available without charge. In 2009, the availability of an open source community edition of IntelliJ IDEA potentially changed the Java IDE landscape.

Groovy: Groovy claims to be “the most popular and successful dynamic language for the JVM”. According to Marx, this certainly seems to be the case (he mentions the high number of books on Groovy (and Grails) and the existence of a DZone area dedicated to Groovy (Groovy Zone) for evidence.

Java EE 6: Marx defines the December release of Java EE 6 as a significant development in the enterprise space.

Oracle buys Sun: According to Marx, even developers who do not use Sun or Oracle products are likely to be at least indirectly affected by this acquisition because it will almost certainly affect the entire software development competitive landscape.

Also included in the ranking were topics as:

• Programming Environments for Mobile Devices
• Bing Search Engine
• Scala
• Java SE 7 News
• Cloud Computing
• Google Chrome OS

If you are interested in Marx’ full review of 2009, please read his blog entry at JW Blogs. He also cited other annual reviews from JavaLobby and Computerworld. So what are last year’s most significant developments in software development from your point of view?

While preparing the second edition of “Groovy in Action”, Canoo Fellow Dierk König once again worked systematically through the language and came across a number of new features that slipped by his attention when they were added. His talk (from Groovy & Grails eXchange 2009, London) presents those features in a workshop-like manner with demos, live coding and lots of interaction with the audience. Watch the video on Skills Matter!

.

Dierk with James Gosling during Jazoon 2009