This year’s JavaPolis (no, someone thought, “we have a great name for our conference but we have to change it, so let’s choose the worst name we can come up with,” and renamed it to Devoxx) for me started off with a university session on JavaFX. I was hoping to get an introductory overview–and that’s what the speakers did give us, just not in a very structured presentation. We dove right into the JavaFX scripting language: this is what a string looks like, this is our home-grown syntax for arrays, etc. Why develop an entirely new language? I get the usefulness of declaratively programming the layout attributes of components, but the language surrounding that might just as well have been JavaScript, Ruby, Groovy or whatever. The rest of the session covered an assortment of concepts of the JavaFX model, interspersed with live-coded simple demos. “It’s this easy to have a yellow rectangle fly from left to right and let it bounce back a little.” “Oh, and here’s a ready-made application [lots of loc scroll by] to display 9 photos in a window with rounded corners.”
The integration with Illustrator certainly did look handy. Named layers in Illustrator art work become objects you can refer to in the generated JavaFX code. I remember Adobe announcing Photoshop/Flex integration almost a year ago–is it there yet? This could seriously save lots of the tedious work converting graphic designs into application resources right now.

One thing that became clear to me: JavaFX 1.0 as it was presented today is not ready to build serious enterprisey applications. Yes you can have flying, rotating and fading rectangles. You can display photos from Flickr in those rectangles. You can even embed a media player to display a movie trailer. But almost all components still have to be developed for JavaFX (or rather, reused from Swing). We’re a long way before JavaFX will be a serious competitor to Flex.

Twenty years ago, my first job was to assist visitors of the Computerette — something of an Internet café without the Internet. This small company had been started by someone who did freelance jobs coding some very obscure Cobol dialect. While he kept doing his well-paid job, he hired me to take care of the shop. Besides this rather dull work, he let me do small programming jobs on the side. For this, he introduced me to Clipper, the compiled variant of the then-popular dBASE III language. Himself, he would not dream of quitting his Cobol job for this; even though he loved Clipper and Clipper jobs were abundant at the time. “It’s not about the language,” he told me, “it’s about the problems you’re asked to solve.” While I was coding my first address book application for a start-up law firm, his software was controlling the oil refineries of Pernis (the Rotterdam harbour). I did not understand him back then. Who ever would want to keep coding in Cobol, the language of the past?

At yesterday’s RubyEnRails 2008 conference, a friend told me that I’m in a golden cage: getting paid more in my current job for coding Java, than I could get in another job for doing Ruby/Rails — preventing me from switching to Ruby/Rails. His remark reminded me of my old boss who did not want to switch to Clipper. Am I turning into him? Am I coding in the language of the past? Will I still be doing so 10 or 20 years from now?

Whatever. It’s not about the language.

How about those annotations? Haven’t they made the once simple and elegant Java language into a unintelligible mixed-up mess of code and metadata? These are just two outcries of despair about annotations that I found on the Internet, both written by able and experienced Java developers:

“We have been seeing this for awhile via XDoclet, and the .NET community is definitely seeing it. I dunno, maybe it is just me, but it scares me. We need to get out some practices for what should be in annotations, and really hope specs will not do crazy things which have you nesting them 5 times.”
techno.blog(“Dion”)

“While the advantages of annotating the code (JSR 175 – Metadata Facility for Java) are somewhat clear to me, I have been wondering what the drawbacks could be. I don’t deny that being able to specify auxiliary information for classes, interfaces, fields and methods is a good thing. What I question is the means we will supposedly use to achieve this, namely, we will be putting the whole stuff directly within the code. If not used with care, annotations could (and most certainly will) massively contribute to code pollution […]”
Val’s Blog

Next, take a look at this code sample and see if you can make sense of it.

@C1(C=2) @C2(C=3) @C3(C=4) @Private(access=PUBLIC) public class c {
    @X1(Y=1) @Y2(Z=2) @Z3(X=3) @Public(access=NONE) private int i;
    @A1(X="A") @A2(X="B") @A3(X="C") @A4(X="D") public void f() {
    }
}

This is what happens if you unleash a new language feature like annotations into the coding community. All sorts of people start using them to create the worst kind of code you could imagine. Do we really want to enable exoting programming styles like these? Would you want to maintain code like this, with annotations in them?

Of course I’m not serious here. Josh Bloch however, was very serious when he used the exact same arguments against the BGGA closure proposal, in his presentation at JavaPolis the other week. Not that he’s completely against closures, but he did fall back on fallacies like these to scare the audience before coming up with some real arguments against the BGGA proposal. And even those where carefully constructed to discuss only the most complex examples from the BGGA proposal. He “forgot” to show some examples of how closures might actually make life (and coding) a lot easier. Which one do you think is easier to understand and maintain, and is less error-prone?

With closures:

doTransaction(entityManager, {=>
    Person p = new Person("Last name");
    entityManager.persist(p);
});

Without closures:

EntityTransaction tx = entityManager.getTransaction();
try {
    tx.begin();
    Person p = new Person("Last name");
    entityManager.persist(p);
    tx.commit();
finally {
    if (tx.isActive()) {
        tx.rollback();
    }
}

The one thing I agreed upon with Bloch in his presentation, is that there already is a Java-like language that has closures (among other things) incorporated from the start, and that is completely compatible with Java. That language is Scala. It is tempting to leave Java be and turn our attention to the next step in the evolution. Tempting. However, Java is not dead, not even nearly. The reality is that most of us will be coding in Java for many years to come. Our communal knowledge base and level of understanding of the language will only grow, allowing for more complex features to gradually be built into it–and at the same time, make our code clearer and our lives easier.

Neal Gafter (black hat) watching Josh Bloch’s presentation at JavaPolis 2007

Thursday’s JavaPolis keynote starts with Bruce Eckel doing basically a partner slot — a 45 minute promotion speech for Flex (what else). What’s this doing at a Java conference? How much did Adobe pay for….. — Oh. Okay. I just saw the first demo. I want to use this! Show me more! And it works in everything with a Flash player on it? Where can I sign up?

Stephan Janssen’s keynote on his side project, parleys.com, (no seriously, there’s some great stuff on there and the new (Flex) version looks very slick), gives me some time to recap the last two sessions I saw yesterday. As planned, I chose the EJB 3.1 session over yet another intro into JRuby on Rails. While EJB 3.1 promises some useful new features (WAR packaging, singleton beans, timer service etc), a whole hour is a lot of time to listen to the ins and outs of features and subfeatures.

Then came the moment we’d all been waiting for: a panel discussion with James Gosling, Joshua Bloch, Neal Gafter and Martin Odersky about the future of computing. Literally the future of computing, where most of us had expected or hoped to see a discussion about the future of Java. So what did I learn from this?

1. Interviewing is a real profession. A panel like this needs a good host who will ask the right questions, ask follow-through questions that are on everyone’s minds, and most of all, can keep the discussion going. Uncomfortable moments of silence at a table with guests like these, with about 2000 people watching, just shouldn’t happen.
2. “Closures are sexy.” Guess who said that, completely out of the blue? But more importantly, why didn’t the interviewer touch the subject that everyone expected to guarantee some fierceful debate?
3. a < b is not the same as a – b < 0. In C. I think that’s even a better t-shirt text than “There’s only 10 kinds of people: those who understand binary arithmatic and those who don’t.”

The Keynote Continues

Sun’s Tim Cramer is next on Thursday’s keynote. “Who’s programming Java ME?” he asks the audience. About five people raise their hands. “Who’s done it with NetBeans?” One hand remains in the air.

This shows my doubts about the ever-recurring Sun demos (usually during keynotes) with SunSpots, robots and phones. Fun stuff, but how many of us are actually using it? Most of us are developing web apps — which is not to say that there shouldn’t be attention for anything beyond that, but this is overdoing it.

One last observation: while I’m in deep concentration for writing this blog post, I suddenly hear Sun’s Java evangelista Angela Caicedo talk about “moving my guys around.” Huh? Oh, she’s talking about sprites.

Bob Lee’s session on Guice got mixed reviews. Having already seen his introduction to Guice, I had an pretty good idea of what Guice is, so I enjoyed hearing about his 50 or so best practices and previews of things to come. However, I spoke with another visitor afterwards who was less impressed; he had expected more of an introductory session.
Right now I’m in a GWT session where one of the speakers has been delayed and time is being killed by someone demoing GWT applications somewhere on the Internet, followed by another substitute who starts his presentation with the announcement “Let’s see how fast we can go through this stack of slides.” and welcomes every slide with a half-surprised “Okay…” — has he even seen these slides before?
To start the day off, there was a triple keynote: Stephan Janssen, building up via Bruce Eckel to James Gosling himself. Something that caught my attention on one of his slides: Java would enable you to “Learn Once, Work Anywhere”. Is that really true? Even in the Java EE world I’m in, developers are getting more and more specialized, making a switch non-trivial — let alone the gap that exists between business application and real-time development. Yes, the language may be the same, but different libraries, frameworks, and even the entire context within which you’re working may well require you to virtually start afresh, if you’re thinking about switching.
There was of course some obligatory promoting of NetBeans 6 and Java FX; a short and not very impressive demo with Sunspots and robots (read the book, seen the movie — again!); and a plea to Neal Gafter to get closures into Java 7. Which is kind of weird if you think about it: the “father of Java” asking a Googler to please implement the feature the he himself was unable to include in Java in the first place.

Simon Ritter doing a robot demo

Near the end, I saw a JasperSoft employee losing about 5 litres of sweat: his guest appearance in Gosling’s session went sour when the beamer, switched over to his laptop, remained black for an uncomfortable number of minutes. The gum he was chewing did not help his demo either, by the way.
The GWT session did not end well. Both guest presenters battling for attention, both ignoring any comments one makes about the other’s slides; as well as the text on half of the slides being garbled and unreadable… Fortunately GWT looks slick enough (both code and end result) but definitely needs better promotors.