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

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.
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.
I'll suppose my students will learn more about that next year :-)
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”.
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.
