JavaOne Day 1: Scripting Everywhere
If you were new to JavaOne, you might be forgiven for thinking that the message was - Strongly typed languages are so-90s, scripting is in! And why wouldn't you - every other word you heard was - JRuby, Groovy, Server-side JavaScripting. And if that wasn't enough, Sun introduced a half-baked, half-after-thought, all put-together-in-a-last-minute-sprint JavaFX. Ok so I don't want to disregard the hard work put together by folks to get JavaFX ready for JavaOne but it all seemed so unconvincing. The demos were clunky, some didn't work and those that did were hardly "Wow!".
Nothing to "Wow!"
If you like showtime, there was none. No big announcements, no new features, no gennext projects. But IMO that was a good thing. Java has seen many evolutions, many innovations. It's time to make it just a little better, a little more robust, a little more performant. Java is a mature technology now and any radical change might actually be shaky news for the massive Java community.
Oh so Groovy
As I mentioned - scripting languages were the talk of the day. And Groovy is one of them. It has been around for a while and the rich set of features it offers are testimony to that - Java-like syntax, pre-compiled or runtime compilation, "duck typing", annotation support and a whole pageful of other features.
I wonder what has lead to this sudden wave of dynamic languages? Wasn't it only yesterday when everything-should-be-strongly-typed was the hallowed rule of programming. Maybe it's the advent of mashups. Maybe the uptake in AJAX. Or maybe we just need something new to keep us interested!
Web as a platform
"Integrated rich clients" - or what we know as mashups - are the killer apps of the day. Things (technologies, techniques, hacks) that allow for mashups to be assembled with minimal code will be on the victory parade. More code is executed on the client but most of that code is still sent to the client by the server. No wonder scripting is big today and getting bigger. But what I do wonder is where does that leave EJBs / ESBs?
JSR 311 - Java REST API
I had questioned the need for frameworks to build RESTful services earlier. And after having sat thru a session explaining the new Java REST API spec I am no more close to getting an answer to that. Ok so they showed a few annotations which got rid of a few lines of code. But does the same simplicity work if I have even a slightly complicated URI pattern? Or will it work if I don't use the "Accepts" header for conent negiotiation and use query params or path extensions? And from what I saw it seemed they were generating XML and JSON from Java code. Aren't JSPs (or any template technology) a whole lot easier to do that?
I got Closure
Neal Gafter gave a presentation on Closures in Java. Very well done, no gimmicks, to the point. A great presentation for a potentially very powerful feature in the Java language. If Neal needs more voices to move this up the JCP and into Sun's plans for Java SE 7, count me at +1.
Take home point
Like 'em or hate 'em - scripting is in town.
2 comments:
//
JSR 311 - Java REST API//
Any idea where are we on this?
Well written article.
Post a Comment