Source available for one of the coolest JavaOne demos (ever?) – the Aerith mappping app

The team at Sun Swing labs responsible for putting together one of the best looking and coolest JavaOne Swing demos (possibly ever?), and possibly the best looking Swing app ever, have released their source code on java.net – check here for the project page.

The app itself is a ‘mashup’, a combination of web services to provide a single application. The app uses Google Maps, Flickr, and Yahoo’s geocoding webservice to allow you to create and share slideshows of road trip photos.

This in itself is a pretty neat application, but the major selling point of this app is that it is a truely awesome looking Swing application. If you haven’t seen the screenshots, go to the site above and check it out, because this will blow away all your misconceptions about what a Swing app looks like and what is possible with Swing.

Groovy JSR-06 released

Groovy JSR-06 has been released, which is the final step before a Release Candidate release – in other words, we’re getting close to a final 1.0 release of the Groovy scripting language.

If you haven’t checked out this language yet I urge you to do so… for simple development related tasks where you just need to knock something together quickly, Groovy’s simplicity cannot be beaten.

Check here for a list of changes and additions in this latest release.

Are Java EE 5 simplification improvements good enough?

InfoQ.com has a round up of a number of articles asking the question ‘Is Java EE 5 lightweight enough?’

EE 5 has made a huge change to EE development with the use of ‘sensible defaults’ and annotations replacing much of the Deployment Descriptor Hell, but maybe the parties involved in the JCP process who defined the EE 5 spec did not go far enough. Richard Monson-Haefel, an analyst with the Burton Group and long time J2EE book author, comments in this article that there is a growing trend to take a ‘pick n mix’ approach to Java EE, where people are taking just the parts they need and enabling their use with other frameworks like Spring.

This is a good thing in my opinion, as firstly, no-where in the EE spec does it suggest you use every part of the EE spec – you choose the parts you need for solving your current problem. Spring goes an extra step to enabling this approach, as it enables the use of services previously only available and usable (easily) within an EE container, the application server, which depending on whether you prefer purchasing from a major vendor or using an open source solution, may cost you in the region of multiples of $10k.

The next threat to EE is the advent of alternative approaches to the EE monolithic approach, such as those spearheaded by Ruby on Rails and the many other frameworks introducing similar approaches. EE can only learn from the benefits being introduced by these frameworks. The article mentions an important point though – can EE adapt quick enough through the JCP process to offer these improvements that people are looking for, to keep people with the EE platform instead of moving elsewhere?