O’Reilly’s Web 2.0 conference starts tomorrow in San Francisco, and you’ll probably be hearing about it a lot this week. In fact, we’re featuring Tim’s essay What is Web 2.0 on ONJava starting Wednesday night, to help Java developers understand these changes and new ideas.
And I imagine a lot of you are going to say: Where’s the Java in Web 2.0?
Fair enough. In fact, the word “Java” appears only once in Tim’s essay, in a section on “Rich User Experience”:
As early as Pei Wei’s Viola browser in 1992, the web was being used to deliver “applets” and other kinds of active content within the web browser. Java’s introduction in 1995 was framed around the delivery of such applets.
So, you might be saying, the last time that Java mattered in terms of Web 2.0 was ten years ago?! That’s not quite true… but it’s not all wrong either.
Reset. Let’s define what we’re talking about. Tim offers seven principles of Web 2.0:
- The Web as Platform
- Harnessing Collective Intelligence
- Data is the Next “Intel Inside”
- End of the Software Release Cycle
- Lightweight Programming Models
- Software Above the Level of a Single Device
- Rich User Experiences
How do these relate to Java? The key may be understanding that Web 2.0 primarily operates further “up the stack” than the language level. Tim makes this point by comparing Netscape and Google — the browser doesn’t matter anymore, what you do with it does. Given this, many of these values (particularly 2, 3, and 4) can be achieved with more or less any language.
Java figures in point five… arguably as an example of what not to do. Java programming isn’t lightweight, and you need only a single 1500-page J2EE tome to remind you of that fact. Java’s intrinsic philosophy is to catch everything at compile-time, to treat all significant activity as strongly-typed interfaces whose actual implementations may be provided at runtime, but whose signatures need to be known ahead of time. Even the most flexible and robust of Java’s network frameworks, Jini, exhibits this philosophy. The web services frameworks are heavily tilted towards equally formal standards, like SOAP. But look at what Tim notes about this approach:
Similarly, Amazon.com’s web services are provided in two forms: one adhering to the formalisms of the SOAP (Simple Object Access Protocol) web services stack, the other simply providing XML data over HTTP, in a lightweight approach sometimes referred to as REST (Representational State Transfer). While high value B2B connections (like those between Amazon and retail partners like ToysRUs) use the SOAP stack, Amazon reports that 95% of the usage is of the lightweight REST service.
The formal Java developer will presumably cringe at the brittleness of parsing XML from an HTTP stream and simply hoping that it’s well formed and makes some kind of sense — wouldn’t it be better to lock this stuff down with a nice RMI call? — yet that simply isn’t how things are being practiced.
Point six: software above the level of a single device… hello? Remember us? Write once, run anywhere? Surely everyone’s got at least one t-shirt or other piece of conference schwag with that motto, right? Well, what the hell happened? Last I checked, most Java developers were on the server side, where the “everywhere” is a very specific “somewhere” that could have been spec’ed and coded to months or years in advance. Java applications and applets hopping from device to device? By and large, it’s not happening. In fact, Java SE seems firmly wedged on the PC, apparently not relevant to other devices well-capable of running it.
Interesting thing to note, though: Tim’s examples of this principle are iTunes and TiVo. Those are not cross-platform applications. What matters is that the media they play crosses devices, but the software in the iPod is not the iTunes code-base, nor does the iTunes Music Store need the capabilities of the iTunes client. The credit here should go to the standards bodies like MPEG. Same goes for the TiVo Media boxes that host and swap MP3’s and JPEGs.
To me, that smells like an opportunity. In the iTunes case, two of the devices involved in the value chain — the computer and the iPod — have a fundamental need for some of the same capabilities: playing music, reading its metadata, organizing the music, etc. Java across devices means your media management apps could travel with your media, a premise I explored long ago in What If the iApps Had Been the jApps?.
There are technical hurdles — Java SE still has a distribution problem, it’s not a genuine super-set of Java ME, small devices are notoriously variable — but at least we can offer an alternative to writing your app all over again for every device in the chain. It’s an important step.
Point seven: rich user experience. OK, raise your hand if you implicitly trust AJAX. Now how many of you with your hand up run IE on Windows?
Java has a far stronger compatibility story, one that just works and will satisfy those critics who will put aside their prejudices long enough to look. For a client-side story, it’s worth looking into Java Web Start. This technology has had a rough history, but it’s finally delivering for a lot of people. If you have JWS — and if you have J2SE 5.0 or if you’re on Mac OS X, you’re good — try out this Web Start-ed Sudoku app (more info on its home page). Web Start also speaks nicely to the Web 2.0 principle of “End of the Software Release Cycle”, as each launch of a JNLP file can check back at its home page for updated code, allowing the developer to constantly update clients with minimal fuss.
So there potentially is a Java side to Web 2.0… what remains is for developers to realize that Java is a compelling, quality technology that solves real problems at important points of contact in the Web 2.0 world. The open-minded will be able to see past what’s cool and what’s hot and I think they’ll find that in some cases, Java is what works.
Will Web 2.0 be Java-powered?