Skip to main content

JavaOne 2011 Day 4

Posted by cayhorstmann on October 7, 2011 at 4:42 AM PDT

Another day, another keynote. A fellow from IBM talked about cloud stuff. I sat through a lot of nebulous cloud talks, but this guy was good. He had a sensible slide on architecural alternatives, explained why we should all go out and buy a device for a ”data grid”—a memory device for sharing data among VMs—and he gave a demo of some software for configuring an app to run on their cloud server. Clear and to the point, like a tech talk should be. It had nothing to do with the “community” theme of the keynote, but you can't have everything.

Sharat Chander made the obligatory comment how the Java language was not all that important, but that the most important element is the community. I used to think that was just talk, but today, it made me think of a programmer who was ticked off for having received condescending answers on the mailing list. He wrote on Reddit “I tried to use Scala, and found it has one major disadvantage going for it, the community.” I can see his point. The Scala community can sometimes feel like a faculty commons room where everyone wants to prove that they are the smartest one. Martin Odersky, the creator of Scala, posted a plea on the mailing list to be kinder to newcomers, and it started a long discussion, some civil and some condescending. Apparently building a language is easier than building a community.

I had never quite realized to how much effort it must be for Sun and now Oracle to build that community. They do put a lot of thought into it. There is community involvment at multiple levels (JCP, JUGs, champions, education, etc. etc.). Managing that costs time and money, but I think the results are quite spectacular. When I work with other technologies, it is normal to see vendor support for fanboys or “valuable partners”. It is rare to have support for a vocal bunch of people who forever complain—because they love what they have but want it to be even better.

John Duimovich from Eclipse was on the stage and said that maximum effectiveness requires transparency. But it's hard to do. It's a culture change. It requires reinforcement from management and a sustained push from the community. Sharat asked ”How patient should we be?” His response: “You should be very impatient.”

That's how I feel about open-sourcing and standardizing JavaFX. Very impatient. I don't quite see why I should have to wait until the end of 2012 to run it on my favorite development platform. After the keynote, Peter Pilgrim (a fellow Java Champion and early JavaFX user) reminded me that JavaFX used to be in an open-source repository, but Sun closed it up.

JavaOne content will be available on parleys.com. Make that some contents. 40% of presentations will be released, starting with 20 talks and today 3 talks a week throughout the year. Parleys is hosting the content for free, but Oracle has to do the video production, which is not cheap. Stefan Janssen from Parleys suggested that the audience should put pressure on Oracle to have all talks available :-)

A fellow from Rockwell came to say how his company loves embedded Java. Then he left.

Come on guys—with embedded Java, you can show stuff. Robots, machinery, dials and gauges, whatever. Bring it on the show floor or, if it's too big, show us a movie. James Gosling used to have a toy show at the closing keynote. Bring it back!

The Sodbeans environment got a Duke's choice award. It allows visually impaired people to work in a modern programming environment. They have an “omniscient” debugger that can step backwards in time (and, of course, also forward like the usual debuggers). It talks, informing the programmer how the program state changes. They are also working on a programming language that is especially suited for screen readers, which sounds like a very interesting design challenge. It will soon come to the Java VM.

Finally,  jHome is an open-source home automation system, built on GlassFish and Arduino. What is it good for? It can control lamps, locks, thermostats, and most importantly, in the home of a programmer, the coffee maker.  You can use CDI to inject a CoffeeMaker object into your JSF page, and use an EJB timer to turn on the coffee maker in the morning. “What does the j stand for?” asked the moderator. 

Being a sucker for talks with snazzy titles, I went to “HTLM5 and Java: The Facts and the Myths”. It turned out to be about Project Nashorn, the new and improved JavaScript runtime for the JVM. It is a myth that this has any useful connection with HTML5. There was a proof-of-concept demo of Webkit running Nashorn, but so what? What's the chance of IE, Chrome and Firefox ditching their JavaScript runtime for Nashorn?

I finished the afternoon hanging around the Mason Street Café, talking to various Oracle people who weren't supposed to talk to me on account of my bright orange press/blogger badge. Later it was suggested that Google's new programming language, Dart (which is described as a JavaScript replacement) might give Google a way of replacing Dalvik on Android with a JavaScript VM, giving them an out if the Oracle/Google lawsuit doesn't go their way. If so, it's even more unlikely that Chrome will want to switch to Nashorn.

Overall, the message that I got from this year's JavaOne is that Java SE and EE are alive and kicking. Finally, we have a good roadmap for Java SE 8 and 9. Java EE is doing great under an open process, and I am pretty confident that Java SE will get there (maybe not quite as quickly as I'd like). After four years of false starts, JavaFX has finally found a home as the presentation technology in Java SE. I just re-read my Java One blog from four years ago. At the time, my reaction to JavaFX was that I needed a new scripting language like I need a hole in my head, and I didn't want to write Flash in Java. I just wanted better client-side Java. It looks like that's what we'll finally be getting.

The conference location was ok, nowhere near as nice as Moscone but not terrible. The best part was the Mason Street Café, the block of Mason Street between the conference hotels. Attendance was up, and I ran into lots of very interesting people—that (and not my love for keynotes) is the real reason why I love going to Java One. I look forward to Java One 2012.

Related Topics >>

Comments

Nashorn is not meant to be adopted by the big mainstream ...

Nashorn is not meant to be adopted by the big mainstream browsers. It has other goals:

  • Simply replacing the slow, aging Rhino which is included in the JRE. Rhino/Javascript themselves are not a standard part of JavaSE, but they are a reference implementation of javax.script, also Javascript is necessary in the Java Plugin to parse proxy auto-configuration scripts (PAC scripts are actually Javascript code).
  • Avoiding the need to ship JavaFX with WebKit's own Javascript VM. Nashorn will be smaller and more lightweight, because it will be just a small Java library, and not a full-blown independent virtual machine with its own JIT, GC, heap and other runtime needs. The Java/Javascript communication will be mush faster too, just Java objects invoking each other instead of going through two separate native interfaces, one from Java to native and other from native to Javascript. Swing/SWT apps that use WebPane will benefit in the same way, but JavaFX will see the most benefit because it also supports Javascript scripts inside FXML files.
  • And maybe, we can also use Nashorn to provide a competing runtime for things like Node.js. JRuby is already good precedent. But Javascript is a better candidate to be the ideal scripting companion to Java, because like it or not it's massively popular thanks to the web. I can see people adopting JS in other places where a scripting and/or dynamic-typed language is desired, e.g. inside rule engines, instead of new languages like Groovy.

Thanks, that all make perfect sense. I very much like the ...

Thanks, that all make perfect sense. I very much like the idea of a better JavaScript engine on the VM. I was just frustrated with the presentation--it made a big deal of an HTML5 angle that never materialized.

Nashorn is in fact very important for all dynamic languages ...

Nashorn is in fact very important for all dynamic languages on top of the VM.
Exactly like Grizzly was important for all Java webservers because it helps to solve a lot of NIO performance bugs and provide concrete use cases that lead to the introduction of async IOs in Java 7.
Because Nashorn has to be a fast javascript engine to compete with Mozilla *Monkey and Google V8, I expect to see VM performance improvements and introduction of new VM mechanisms like tagged pointer or coroutine.

Rémi