Day 4 of Java One is over. Even without huge announcements or great surprises, it was a great conference. Here are my impressions from the cool stuff keynote and my takeaway what it all means.

The Cool Stuff Keynote

My mind wanders during most keynotes, but I always enjoy James Gosling's cool stuff keynote on the last day of Java One. No marketing, just one amazing Java-powered piece of hardware or software after another. Here is what caught my attention:

• Tor Norbye demoed the JavaScript support in Netbeans. Here is a man who can give a better presentation typing code on the screen than most people can with the slickest slides. (Not wanting to name names [Hi, Ed...] but this is not something most presenters should try...) He types a line of code, something cool happens effortlessly, whoops, he makes a typo...no, that wasn't a typo but a calculated manoeuver to show off error handling. A few years ago, I saw him briefly flustered by a bug which he fixed on the fly, talking all the time as if nothing happened, and then he continued the demo.

  Those Java-powered micro-sensors draw so little energy that they can be powered by ambient vibration. The presenter gave one convincing application: sensors in beer coasters that would communicate through the mesh network which glasses were empty or not cold enough. I suppose the sensors ask each other: “Do you come here often?” A bit off-topic...so many engineering colleges persist in teaching C++ to freshmen because obviously nobody would use Java for embedded development. With the sensors, smart cards, and industrial controls that we saw today, I am not sure how much longer that will be the wise choice. My guess is that the users of those technologies are willing to pay for the Java layer because it gives them ease of development, my personal theme of this Java One.

• James Gosling asked the fellow who showed off the Java-powered Pulse pen the exact question that was on my mind: “Why would anybody want a computer in a pen?” But the demo was very impressive. Check it out on the video, starting at 56:15. Too bad the docking requires Windows.
• The keynote ended with some big science: JMars and the use of Java at CERN. When Gosling visited a control room at CERN that was filled with monitors, he asked whether they had any Swing apps. Well, all of them were Swing apps.

Concurrency

Unfortunately, I managed to miss two good talks by Brian Goetz, which does not stop me from pontificating about concurrency, of which I know very little. Check out the excellent slides for TS-5515 and TS-6206. TS-5515 is about the fork-join framework that lets you parallelize certain tasks (such as searching or combining array elements) with a fairly reasonable syntax (which, BTW, would look quite a bit more reasonable with closures). The reason I am getting concerned about this issue is neatly summarized in the overview slide of TS-6206:

The hardware, the OS, and the JVM are ready for large numbers of cores.

The languages, the tools and the programming community at large are not ready for large concurrent programs.

So... good luck, guys!

Last year, Brian had suggested that I check out actors and software transactional memory. I managed to learn a bit about actors, by the expedient device of assigning my students lab work with Scala actors.

Actors share no state...except when I am a knucklehead. The Scala actors are closures and—Josh Bloch will love this one—more than once I accidentally captured a variable from an enclosing scope in an actor. Ok, they don't share state, and they communicate by sending messages. So, you break up your task into actors, each of them does a bit of work, and then they send a message to some other actor that combines the results. How does it know when it is done? You send some other message with a total count. It takes a bit to get used to it.

I then solved the task with Java locks—tedious as usual, and the nagging feeling that I overlooked something, as usual. Finally, I used java.util.concurrent. That was pretty easy...for me. Judging from some very blue-collar comments on the class discussion group, some of my students had a much harder time with the Java constructs than with actors. So, maybe actors are good, and in Scala, they can certainly scale. But concurrency utilities are also good, if you know what you are doing. (Buy Brian's book...)

In the presentation, Brian writes: STM (Software Transactional Memory) is a not-yet-here technology that takes locking decisions out of the users hands.

• Commonly compared to "garbage collection for concurrency"
• With a name like that, who wouldn't want it?
• Despite widespread enthusiasm, still a research subject

I'll suppose my students will learn more about that next year :-)

Web Services...Not!

When SOAP web services first appeared, I thought simple...object...who wouldn't want them? Well, when I was bombarded with JAX-this and WS-that, when all I wanted to do was get some stuff from a server, I felt like those people in the “future Java features” BOF. I knew I wanted something...just not that. I looked at the TS-5425 slides to see whether REST would save me, and I am cautiously baffled.

So...here is my test to see when web services have truly arrived... Today, being a packrat, I downloaded all the presentation PDFs. I manually logged in to the schedule builder, queried for all sessions, did View Source, saved the source to a file, and ran

for f in `grep -o "/[^/]*.pdf out.html` ; do echo wget --user contentbuilder --password doc789 http://www35.cplan.com/cb_export/$f ; done

I know that web services have truly arrived when that most pathetic of tools, Sun's schedule builder, publishes a web service (SOAP or REST—their choice) that lets me get the schedule data as objects and stash away the presentations, without scraping HTML.

In the meantime, if anyone has a pointer to some tool that records browser activity over multiple pages and gives me Java code to replay it (for HTTPUnit or something similar), I'd be very grateful. I have to do HTML scraping all the time with the IT systems at my university. Nobody there is telling me “just call this web service”.

What Does It All Mean?

Another Java One is over. I had a great time meeting a lot of interesting people, I learned a lot, and I think it is an excellent conference even when there are no huge announcements or great surprises. Here is my personal take-away.

• Incremental improvements. One of Germany's great post-war politicians, Herbert Wehner, likened politics to the tenacious drilling through thick pieces of wood. The Java community has that tenacity. Bad stuff gets fixed, and good stuff just get better every year. If you hated Java technology X, have another look. Chances are it is much better today. The Swing app framework, JPA 2.0, Web beans, ever more amazing IDE support, are all very good at reducing drudgery and increasing productivity.
• Multiple languages on the JVM. As much as I would personally like to see more vigorous evolution of the Java language, I can appreciate that the majority of Java users don't share that eagerness. Mixed-language use will become a fact of life. It is just a matter of time when I'll start a project in my IDE and, instead of choosing “Java project” or “Scala project”, I'll check multiple boxes.
• Healthy skepticism, transparency, and community. As an Apple developer, you better like Kool-Aid. As a Windows developer, you are stuck with what is handed down from the top. In Java, you don't have to love everything, decision making is by and large not a black box, and the community gets to participate.