John D. Mitchell's Blog

Web Services and XML Archives

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

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.

JavaScript

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).

Concurrency

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.

DSLs feelin' groovy (or, graduating from elementary school)

Ben Galbraith has posted the first of a series of blog entries about How I Learned to Love Domain-Specific Languages. It's great that more and more people are starting to see the value of explicit, focused languages over ridiculously inhumane "formats" like XML. Hopefully, we're finally reaching a tipping point.

Explicit DSLs feel weird to a lot of programmers because there's been so little mainstream focus on them. I.e., as shown by one of the comments, developers have been herded and otherwise sucked in by shiny-looking tools (by poor education, management, laziness, peer-pressure, ignorance, lack of training, marketing hype, etc.) and haven't (consciously) realized the power of domain languages. It's amazingly odd to me how little energy has been applied to languages among mainstream developers given how much programmer time is spent arguing about the minutia of programming languages and tools.

The fact is that we're already surrounded by and are constantly implementing "DSLs". Look at the "language" of printf and friends, the declarative "specification" of makefiles, the myriad "protocols" that we deal with everyday like HTTP, SMTP, SSH, and FTP, the "APIs" of code libraries, the "design patterns" embodied in frameworks, the analogies and "metaphors" we use to described software architectures, the implicit languages that we create each time we define a class, the jargon we use to talk with each other, etc.

A big part of the problem that I see happening right now is that too much of the discussion around "DSLs" is being framed as some sort of "either/or" / "black/white" conflict when it's really just a more conscious and explicit approach to things that we've already been doing. Whether it's the hype juggernaut of Ruby on Rails or the Java is old, boring, bloated, etc. ideas exemplified by Beyond Java or the "IDE" wars between Eclipse, NetBeans, IntelliJ IDEA, and Emacs, or whatever, the biggest issue with this "us/them" thinking, IMHO, is that people are fighting the wrong fights. The leverage that matters most is the ability of developers to think and communicate clearly with themselves, each other, systems, business folks, and users. Biologically and sociologically, human are built to be linguistic.

That is, languages are fundamental to how we work internally and with each other. Sure, we have various tools to help us communicate but isn't it clear that e.g., PowerPoint isn't the point, it's just a tool — and, alas, a tool that usually induces poor communication rather than enriching conversations). On the other hand, look at the "modern" killer apps and how they are all about helping us (manage our) communicating: email, web, blogs, P2P, wifi, cell phones, faxes, VoIP, agile/XP, open source, etc. I.e., we've graduated from the elementary school building blocks (word processing, spreadsheets, databases, Belief of Control, etc.) to the middle school of communication. Now, we just need to learn and develop languages and tools built around this new level of understanding and put aside our old, comfortable, but ultimately dead-end habits.

Binary XML?

Well, there's seems to be a fair bit of discussion lately about various approaches to making XML less of a bloated sack of protoplasm. Technically speaking there's a Sun article on talking about the Fast InfoSet draft specification. More generically speaking, here's a CNet article asking: How do we make XML faster?

• If binary XML is the answer, what exactly is the question?
• If XML is the answer, what is the question?
• Why are people using XML for so many things that it's horrible for?

IMHO, all of this stems from the fact that people have been mislead by XML's name into believing that XML is a language when XML is really just a data format. Very sad.

Why Humans Should NOT Have to Grok XML

Terence Parr, creator of ANTLR, wrote an excellent essay on why humans should not have to grok XML.

This work is licensed under a Creative Commons License.