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?
Seriously, Google Maps is great and all, but I’m really leery of compatibility. Remember, there isn’t even a standard here, just some widely-held ideas about stuff known to work with (some) current browsers. As badly incompatible as JavaScript-heavy sites are across browsers, it’s not a stretch at all to imagine that scenario replicated in the AJAX era, with the other browser makers forever struggling to attain bug-for-bug compatibility with IE, which is the only thing many developers will code for and test against. True story: my last job before moving to editing/writing full time was to convert a Swing app to a DHTML web application. It was spec’ed as running only on IE 6 for Windows, and no time was allowed for testing or fixing on any other browser or OS (or even back-porting it to IE 5). Don’t think that’ll happen all over the place? How many managers out there are interested in spending any developer hours supporting Opera? Or Safari? Or anything that runs on Linux?
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?
Web 2.0 belongs to PHP and javascript
Web 2.0 belongs to PHP and javascript.
Sadly javascript follows java's: may only access what is OKed by the language designers. Contrast this to python or PHP com access /C# (pinvoke).
Point 5: 1500 page spec says it all.
Point 7: Java user interfaces are still not as responsive (no flame intended..).
If only a standard datagrid (that looks and feels like excel) were included in browsers (although openrico does this quite good in javascript).
None. At least not significant.
I think they'll find that in some cases, Java is what works.
Well, this is far from the not so very old 'java is everywhere' right? What a hell happened in 1 year man? Everybody's jumping ship?
Also take a look at http://weblogs.java.net/blog/editors/archives/2005/10/misfits.html to see how blind some people can be.
We desperately need a 10x productivity framework in java. Trails/Grails ? The ROR storm rages for months now but no solid answer is being seen from the javaland.
Regards,
Horia Muntean
Java owns Web2.0
News.com says ClickOnce, others say Flash.
Check out aggregation, Foaf, etc at a site:
http://roomity.com.
Can you do that in DHTML/PHP?
.V
Javascript and Web 2.0
My perspective: yes, Javascript was buggy across browsers, and no, it's still not perfect. But a LOT has changed since most developers last gave Javascript a whirl: much better DOM support in IE 6, an explosion of js libraries that are tested across browsers, the growing awareness of unobtrusive js techniques, etc. All of these make for a much easier cross-platform js coding experience. Java libraries like DWR hide most of the Ajax stuff from Java developers, freeing us from worrying about the XMLHTTPRequest object, iframes, and the right way to do Ajax calls in IE6 vs. IE7. In short, the traditional barriers to reliable cross-browser js development are rapidly desolving, making Ajax a much more viable alternative to JWS. Though I may be biased because my JWS (Java 5 that I've reinstalled several time) crashes everytime I try to launch something.
There's room for Java...
...but some things will need to be changed.
There's nothing preventing Java from being lighter-weight. You mention J2EE but that's not really pertinent to Web 2.0 (perhaps on the server side, but then only as an implementation detail). What matters is SE and ME. IMHO the primary reason why Java more or less completely failed in the browser is the stubborn idea of the browser-Java folks on "Pure Java" solutions which prevented cross-pollination. If you use Java in the browser you also have to have Java handle the display. There are ways in which you can communicate between an invisible applet and the page's DOM, but they're painful and at best brittle. This means no HTML, no CSS, no SVG, no accessibility, doubled development costs whenever the interface changes, etc. If it were possible to point to a JAR from a script element, initialize a handler object on load, and from there modify the page's DOM, things would have been a lot rosier for Java. I'm personally not a big Java fan, but there are definitely projects in which I would have preferred it over Javascript, and I know many others would have too.
Interestingly, it may still happen. See http://www.w3.org/TR/SVGMobile12/script.html#ScriptElement for an example of this, which could well catch on.
This is lighter-weight because it allows you can have your logic and some DOM manipulation in Java, while all your UI is where it should be, in markup, with all the open data, accesibility, ease of creation, separation of concerns, etc. advantages. We could have had that ten years ago, it really is such a pity that Sun chose an ethnic cleansing to platform design (if you'll allow me to be somewhat inflamatory ;).
But right now the SE/ME stacks are insufficiently integrated. You won't get an SE app to run on ME, and in most cases vice-versa. How dumb is that! The more I think about it, the more I'm convinced SE should just be gone. Looking at what's in the pipeline for the next ME, I'm hard pressed to find much that's missing. Too many profiles just fosters confusion. Anything that's SE today and can't run on the next ME stack should be called EE, and developers should be convinced to target ME as much as they possibly can (especially since they now have technology to address multiple screen sizes and interaction models much more easily). We're very close to the point where Javascript will work in mobile and desktop environments in exactly the same way (that's already the case for the higher-end mobile). If Java can't do that, well, it's DOA for Web stuff. You say it has far stronger compatibility, but that's only true within the small box of a single profile. In Javascript developers have the means to work around compatibility problems (as painful as they find it), in Java you're screwed.
Anyway, enough ranting about Java. I'd just like to point out that the W3C is about to launch an effort to standarize a fair number of APIs for Web Applications, so what's brittle in AJAX today might not stay brittle for long.
will presumably cringe?
"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"
In most cases SOAP ~is~ parsing XML fron an HTTP stream. HTTP can indicate that the content type is XML, and the XML can indicate the DTD or schema. The 95% statistic says it all. Even with SOAP most usage is document based, ie, there is still parsing of an arbitrary XML document that isn't strongly typed via WSDL.