JavaOne 2011 Day 1

Today, JavaOne started officially. With the traditional keynote. Except, traditionally, the keynote is in a huge room that has space for everyone. Today, people were shunted into overflow rooms where they could watch on monitors. In the age of the screencast, that seems pointless—why is that better than watching on your laptop?

I figured I'd just muscle my way through to the press area, thanks to my press pass. Except there was no such area, so I boldly sat with the Oracle executives. Nobody kicked me out, probably because they were all advised by Legal not to talk to any press person.

Tradition dictates that the first keynote is filled with an exciting outlook of the future, perhaps with some boring parts at the end. Not today, though. They got right to the boring parts. A fellow from Intel and a fellow from Oracle bantered about how Intel was helping Oracle and Oracle was helping Intel. Improving Java performance. On the Intel platform. Improve it they did. By a gabazillion percent. Several engineers joined the stage. And talked about how Intel assisted Oracle. And Oracle was forever grateful. For improved performance. By unbelievable percentages. It was painful. More painful for me than perhaps for the rest of the audience, because I was seated next to a high-ranking sales official from Oracle who chuckled at every one of the lame jokes told by the marketing people on the stage, in the way that only marketing people can tell them. Chuckle he did, in the way that only sales people can. Painful it was.

After half an hour, things got better, and Mark Reinhold gave a perfectly coherent presentation of Java 7 (watch the screencast if you've not heard about Project Coin, invokedynamic or the fork-join framework before). He gave a brief overview of what to expect in Java 8 (delayed to sometime in 2012). Closures (project Lambda), modules (project Jigsaw), date/time API. An ambitious release. He tossed about some ideas for Java 9. Self-tuning JVM. Improved native methods. Big data (> 4GB). Reification (i.e. no type erasure, no it vs. Int). Tail recursion optimization. A meta-object protocol. Multitenancy—multiple apps running in the same JVM. These are all tantalizing ideas, and I'll be glad if some of them make it into Java 9. After a long period of near inaction, things seem to be happening.

Next, Richard Baer showed off Java FX version 2. The most important aspect of it is that it is cross-platform (his very words). That' s why they released it today. Exclusively for Windows.

A developer preview for the Mac is on the works. Linux? Not yet. Does it work with Citrix? Remote X? Umm-—maybe not. It relies on accelerated video (which is good when it is there—Swing had a hard time with that). There may be a fallback to plain old unaccelerated video, but what about media? That will eventually be handled by falling back to the platform capabilitites. Just not yet. It will be cross-platform eventually, I am sure. Cross-platform is hard.

Linda DeMichiel gave a preview of Java EE7. Small but welcome enhancement in the core APIs, alignment of managed beans and CDI, and, most importantly, a standard cloud API.

I felt sorry for the last speaker, Hinkmond Wong, who got to speak after the time for the keynote had elapsed. He talked a good game about Java cards and embedded devices. But when it came to cell phones, the audience didn't buy it. Actually, yesterday Terrence Barr told me that the keynote would have some story about some fellow meeting his inlaws in an Indian train station, using a location-aware phone app.

But the actual story being told was about a train station in Oakland, CA. This makes no sense. The Amtrak train from Sacramento to Oakland is often very late, probably much more so than a train in India, so the need for such an app is plausible. But it is absolutely unimaginable that the travelers and the son-in-law would have managed to install a compatible Java app on their cell phones—likely from different carriers, both with punitive charges for installing or using apps on a feature phone—that let them exchange location information.

I left in disgust, but I left to late. By the time that I arrived at my next presentation, all seats had been given out. The good news is that this year, Java One attendance more than doubled (after having fallen by over 50% last year)—that's the most accurate information anyone at Oracle was willing to commit to, provided I hid my press badge. The bad news is that basic commodities such as snacks, paper towels and soap in the bathrooms, seats in presentation rooms, or IP addresses for the wireless network run out quickly.

Fortunately, all turned out well. I ran into the folks at, the company behind Scala. Go there and click on the link that looks like this to get the first chapters of my upcoming Scala book.

Behind the booth I spotted Paul Phillips, my Scala hero who patiently answers thousands of questions on the Scala mailing list, fixes huge numbers of compiler bugs, and knows more about Scala than I can ever hope to. Except, he didn't answer my last set of questions. But he more than made up for that failing. He fixed the most serious issue on the spot, beating the compiler code into submission before my very eyes. Humbled, I promised to do the research on the other issues.

In the afternoon, Alex Buckley (who is still not authorized to speak to me and who incautiously let it be known that this is so because he had not received the proper training for talking to the fourth estate), talked about Project Lambda. It's hard to imagine for us hardcore closure fanatics, but less than 5 percent of the audience are actively following the Project Lambda mailing list. What they are doing instead with their little lives I cannot fathom :-)

So, for me, the big revelation was that it's skinny arrow ->, not fat arrow =>, that is going to be used for anonymous functions such as (x, y) -> x.length() > y.length(). (A month ago, Brian Goetz described a highly scientific process  that led to choosing fat arrow. But that was then.) And that transforming collections doesn't yield the same collections (as it does in Scala). For example, if a is an ArrayList<String>, then -> x.length()) gives an Iterable<Integer>, not an ArrayList<Integer>. In Scala, you'd get another collection of the same type (or nearly the same type—for example, (1 to 100).map(_.toString) yields a Vector since it can't very well yield another Range.) It's the poor man's solution, as Alex admitted, but that's all that the Java type system can afford.

Being a sucker for talks with offbeat titles, I attended a talk on project Jigsaw (the upcoming module system) entitled “Find the corner pieces first”. It was a good, hands-on presentation, walking through the basics of making modules, specifying dependencies, and constructing applications. But then people started asking questions. What about applets that require modules from the cloud? Can they pollute the module repository with evil modules? How about apps  with the usual set of specific Apache Commons dependencies (what I call the Tragedy of the Commons)? What if people cluelessly bundle bad modules? Should they be signed? By whom?  It seems to me that there is a fair amount of work to be done. So, it's probably a good thing that Java 8 is pushed out a bit.

Tune in for more cutting insights tomorrow—that is, if I can get people to talk to me despite my bright orange press/blogger badge.