In the Spotlight - Guillaume LaForge

The Groovy development team and SpringSource are happy to announce the release of the first release candidate of Groovy 1.6.

The JIRA report for this new version lists 74 bug tickets, 26 improvements and 8 new features:
http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10242&styleName=Html&version=14009

Among the bugs being fixed, we tackled issues about:

• the compiler
• bytecode errors
• varargs handling
• covariant returns
• Windows startup scripts

As well as a few regressions:

• the args variable not bound in Groovy scripts
• a performance regression in MarkupBuilder
• a problem with DOMCategory which was particularly problematic for Grails

Fixes in line error reporting should be handy for IDE vendors, as well as for Cobertura code coverage.
Compatibility with Java has also been improved slightly, for instance the empty for(;;) {} loop wasn't behaving the same as in Java (no loop, instead of an infinite loop).

The XML support continues to be enhanced, for instance with:

• better handling of namespaces with XmlNodePrinter and NamespaceBuilderSupport
• new GDK methods in DOMCategory
• you can customize the nodes in XmlParser
• a new builder for StAX, thanks to an external contribution

In other improvements:

• Groovysh can be extended, giving you access to certain key internal structures
• the stacktrace sanitization can be customized should you want to print out nicer stacktraces.
• new GDK methods have been added for File handling and Date formatting
• a new @PackageScope AST transformation was added to support the package-scope visibility Groovy didn't support
• improvements to our OSGi manifest for better OSGi support
• the default resolve strategy used for .with{} method has been changed to DELEGATE_FIRST
• GroovyDoc now supports multiple locations in sourcepath
• an @since tag should be used in documenting the GDK methods so users know when a given GDK method has been added to Groovy

Beyond continuous improvements in Groovy's Swing support thanks to our Griffon Swing team, the Swing console has seen some interesting improvements as well:

• when you have a stacktrace showing up because of an exception being thrown in your scripts, or when you have a compiler error, you'll get clickable messages in the output window, making it easier to navigate to the offending line of code causing the problem
• you can also now opt to hide the script recopy in the output window
• and you can also have a visual representation of output results, for instance with Swing components not attached to any parent being displayed on the output, and the nice thing to consider is also the fact anybody is able to customize the output visualizations.

Last but not least, Vladimir Vivien's JmxBuilder originally hosted at Google Code was contributed back to Groovy, further improving our existing support of JMX.

Beyond all these bug fixes and other improvements, you still have all the novelties and improvements listed in the betas:

• release notes for 1.6-beta-1
• release notes for 1.6-beta-2

Please make sure you try this release candidate within your projects without waiting for the final release, so that we can ensure the final version works well for you.

As usual, you can download Groovy here: http://groovy.codehaus.org/Download

Noteworthy as well is that we have "retrotranslated" Groovy 1.6-RC-1 to JDK 1.4, should you have to stay with a JDK 1.4 for running Groovy: http://repository.codehaus.org/org/codehaus/groovy/

Thanks a lot to all the contributors and committers who made this release possible!

I'm very pleased to echo, here on my blog, the announcement of the acquisition of G2One, the Groovy/Grails company I co-founded, by SpringSource, the company behind the Spring framework!

Everybody knows Spring and SpringSource already, its wealth of Enterprise projects, and how it quickly became the de facto Enterprise standard for building mission-critical applications. Both Groovy and Grails will bring more dynamicity and agility to the Spring portofolio projects, thanks to tighter integration, cross-polination, and further extensibility. At the same time, the two G's will most probably bring a fun coolness factor into the mix, like the icing on the cake!

And you can certainly imagine some areas where integrating Groovy in existing Spring powered projects may be advantageous. Think for a minute about what we could achieve with Groovy integration in the Spring portfolio: think of scripted deployments on dm Server? Writing Spring batch jobs with Groovy scripts, that even administrator could develop and maintain? Easily manipulating Spring exposed JMX beans with Groovy's JMX support? Introspecting a deployed live application with a remote Groovy shell or sending script probes? I'm sure we'll find tons of ways to gain from such an integration.

Also, speaking about integration, let me also mention my pet topic of mine: Domain-Specific Languages. You know it's been a while since Spring supported seamlessly integrating and mixing Groovy and Java wired beans together. But with the high flexibility of Groovy, its malleable syntax and powerful meta-programming APIs, Groovy on Spring will unleash the power of Domain-Specific Languages in the Enterprise world! Subject matter experts can already take advantage of Groovy to write business rules in Groovy for their mission critical applications: but here, Spring would become the fabric tying this business logic to Enterprise services, and Groovy the language for clearly expressing business concerns.

Now, more concretely, for Groovy, what does it mean? I see several key benefits to this acquisition.

First of all, SpringSource's Eclipse team will join forces with our own Eclipse team to shift gears in the development of the Groovy/Grails Eclipse plugin. The lack of state of the art Groovy support in Eclipse can still be a limiting factor to adoption in the wild. However improved the plugin has gotten over the past year, lots of work is still needed to bring it on-par with expectations people have when working with their usual Java IDEs. So hopefully, in the coming months, you should see improved support of both Groovy and Grails in Eclipse.

Secondly, SpringSource has extensive experience in managing community-led projects like Tomcat, so their input will be beneficial to the way we run the Groovy project. Also, don't worry, Groovy will not change its license (Groovy is licensed under the ASL 2 license), or anything like that: SpringSource is committed to sustaining and helping the development of the Groovy dynamic language, to bring it to new heights!

Thirdly, I think Groovy will also benefit from Spring's visibility in the Enterprise space and Java ecosystem by bringing added visibility and better and wider marketing. Although Groovy is already the most popular alternative language for the JVM, additional help is always good to make Groovy even more popular!

All in all, I'm very happy to join SpringSource, to continue developing Groovy under their umbrella and with their help and support, and I'm sure everybody will benefit from this closer relationship between our teams. I also encourage you to read Graeme's post which goes deeper in the benefits for the Grails community as well and read the FAQ regarding the acquisition, as well as the press release. Both Graeme and I, as well as the rest of the G2One team, will remain committed to the projects, and will continue to develop and improve them in the coming years.

I'm really sad to hear the report Kirill makes on Sun progressively abandonning Swing (also posted on java.net).

Swing is really a very good framework for building rich client applications, and from what I've heard and seen, it's even better than what exists in the .Net world, or compared to things like SWT or Cocoa. Sun is leaving a gem in the cold to bet everything on a half-backed JavaFX technology.

With the focus on JavaFX, Sun progressively lost all its key talented employees who preferred sailing to more gorgeous seas -- I can't blame them for that. With the new app framework, the timing framework, SwingLabs, painters, new look'n feels, a wealth of OSS and commercial components, Swing had great chances to keep up with the rest of the world, and even keep its bleeding edge and stay ahead of the curve. Alas, Swing is dying in favor of a new technology nobody cares about -- why would one use JavaFX when Adobe's Flex and Microsoft's Silverlight are so much more advanced and ready for prime-time, thought and tool'ed for the designer in mind?

There are days where I really don't understand Sun and its decisions. Why abandonning such a great technology? I know it's not always the best technologies that win and prevail, but when you've got a competitive advantage in one area, why not keeping it? Instead of betting everything on the new shiny toy of the day? A shiny toy that's been shamelessly crashing all the JavaOne keynote demos?

I'm perplexed!