Java One Day 4
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:
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.
src="http://weblogs.java.net/blog/cayhorstmann/archive/java-pen1.png" />James Gosling asked the fellow who showed off the Java-powered
href="http://www.livescribe.com/">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:
href="http://jmars.asu.edu/">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.
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:
style="float: right; margin-left: 1em;" />
The hardware, the OS, and the JVM are ready for large numbers of
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
In the presentation, Brian writes: STM (Software Transactional Memory) is
a not-yet-here technology that takes locking decisions out of the users
- 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 :-)
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
style="float: right; margin-left: 1em;" />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
style="float: right; margin-left: 1em;" />
- 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
- 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.