Skip to main content

JavaOne 2008: Day 1, The Good, The Bad, and The Lame

Posted by johnm on May 7, 2008 at 6:13 PM PDT

Another year, another JavaOne.

It's always great to see so many old friends again.

This year seems to be continuing the attendance growth trend of the last couple of year so that's a good sign. Also, I've been able to find enough actually interesting and useful talks to keep from going back to sleep and that's an even better sign. In particular, this is starting to show how the "Java community" is growing up and outwards to encompass more than just the same old things.

Here's my list of the key things from Day 1:

JavaFX... NOT!

What a joke. JavaFX was announced with great fanfare at last year's JavaOne and yet what has actually been released in a year? Nothing of value. Just more hoopla and blah blah blah. Way too little, way too late. Especially now that Adobe has started opening up Flash and friends.

Indeed, with all of the improvements to the world of JavaScript/Ajax libraries, frameworks, and tools and most especially with the growing capabilities around the support of canvas in browsers, there's very little real reason to use those wretched "Rich Internet Application" packages like Flash and JavaFX.


Yep, there are now a number of sessions at JavaOne covering various aspects of JavaScript. Large rooms filled with Java developers who are using JavaScript is an interesting site to see.

As Roberto Chinici said in his talk, JavaScript Programming Language: The Language That Everybody Loves to Hate, JavaScript is basically yet another Lisp-1 language. Alas, as was so clearly shown in his talk, JavaScript is a really horrible implementation of Lisp-1 -- so many nasty corners, gotchas, and just plain bizarre things. That said, given JavaScript's ubiquity in web clients and its growing use on the server, it is pretty much required for all web developers to learn JavaScript.

JAX-RS: RESTful services in Java

Yes, REST is here to stay. JAX-RS is the attempt to standardize how to build RESTful services in Java. Basically, the approach is to use a number of new bits of library (such as the URI builder that makes working with URIs actually not a completely bug-inducing nightmare) and a bunch of new annotations.

There are already at least a few implementations out in the wild including the "Jersey" reference implementation and one for the Restlet framework.

The JAX-RS (aka JSR-311) draft specification has just been released for public review -- check it out and send in your comments.

As with JavaScript, everybody doing any web services in Java needs to at least check out JAX-RS (and Restlet).


Is there anybody left out there in Java-land that hasn't yet gotten the memo that concurrency is a big issue today and is becoming a huge issue moving forward?

Brian Goetz's talk, Let's Resync: What's New for Concurrency on the Java Platform, Standard Edition, was primarly about one key way to solve a number of problems was very well attended and people should check it out online.

Basically, coming in Java v7 is an addition to the java.util.concurrent library which adds a lot of support for building Fork-Join style concurrency solutions. For those who can't wait, check out Doug Lea's existing implementation that is part of his util.concurrent library.

Java v7 looks to have some nice features that both allow for very general Fork-Join solutions as well as things like the ParallelArray class which makes it ridiculously easy to concurrently process arrays of information. Joe Bob says: Check it out.

Related Topics >>


It looks like you might want to check out what all can be ...

It looks like you might want to check out what all can be done straight in the web browser itself and all of the good things that's possible straight with canvas.

Des Moines Personal Trainer

Another set of important considerations are usability and testability.

Sure, different folks will arguable about what good usability is but I think we can all agree that there's been a lot of unfixable/un-work-aroundable "rich applications" written in e.g. Flash that are despised precisely because they try to force a very non-web view of the world at the users instead of working with the web style of interactivity. Sure, some of that's ignorant vendors and some of it's the stupidity and arrogance of print and TV "designers" trying to apply their old hammers to a new medium but that's still fundamentally broken.

Also, since those fancy schmancy technologies that you're promoting don't really integrate seamlessly with the browser, they are basically impossible to directly test in an automated way. That makes for a much worse experience for everybody involved.

Dear John,

Sounds like you might want to check out what all can be done directly in the browser itself and all of the cool stuff that's doable directly with canvas.

For example, this processing.js blog entry from John Resig came in via my RSS reader at the same time that I saw your comment. I.e., this is yet another example of how the browser is gaining more and more inherent capabilities (i.e., that do NOT require additional "platforms") to do the actually useful bits of rich application interactivity.

"Disagree about JavaFX. AJAX and other interpreted technologies won't scale"
Ajax runs in the desktop's browser - tell me why it wouldn't scale? What should it scale to? 100 browsers running on the same desktop? You can have an Ajax application without a server - you can scale it up to multiple millions of users without a single iota of degradation ...

Disagree about JavaFX. AJAX and other interpreted technologies won't scale. Plus their model is just WRONG. HTML just cannot deliver a rich experience comparable to the desktop. Sure, you can (slowly) get pretty pixels, but you won't get the rich behavior and transitions available through richer solutions. JavaFX and it cousins Flex and SilverLight are the future of the web. AJAX and JavaScript are here today but gone tomorrow.