Blogs

RedMonk

Skip to content

From JavaOne to Java 2.0: Java is Dead, Long Live Java

Last week was JavaOne. Perhaps the last one ever – its all up to Larry Ellison, Oracle  CEO now, bar the shouting. Whatever decisions Oracle makes with respect to Java, you can rest assured that JavaOne will be a very different event. It certainly will be for us – Sun has been a valued patron of RedMonk and its model over the years, and JavaOne was always a key event in the ongoing conversation.

JavaOne is one of RedMonk’s favourite events. We all like it. Not least because our RedMonk unconference at CommunityOne in 2007 is still fondly remembered by some of the world’s top developers: people like Charles Nutter (JRuby) and David Pollak (Scala LIFT). Why does these guys give us props? Because we were pushing the dynamic language agenda forward at a critical time. Sun has now been a patron of dynamic languages on the JVM over the last few years, and RedMonk helped turn that dial. Sun hired people like Thomas Enebo and Ted Leung (Python) to make sure that the Java Virtual Machine was hot for dynamic languages. Tim Bray was an officially-sanctioned agent provocateur, playing the role of loyal opposition, a grain of sand in the corporate oyster.

Beyond Java The Language

Sun’s moves into dynamic languages were a tacit admission that Java as a language was not the only game in town – which allowed invention to flourish. Netbeans support for dynamic languages was far ahead of Eclipse. Sun’s Glassfish application server was designed in the knowledge Java wasn’t the only language choice for a “java application server”.

Beyond Java The Runtime

Another aspect of Glassfish that has not been much remarked on is that the group behind the code made a very interesting decision. Rather than adopting the Sun and Java Community Process (JCP) sponsored JSR 277 specification for Java class modularity Glassfish went with OSGi. That is, even Sun’s products were “forking Java” by 2008. Instead the newly anointed standard for Java modularity was OSGi. If this all sounds deathly dull its actually pretty important when it comes to Java runtimes. OSGi allows you to build a stackless stack, where modules of Java classes are loaded on demand.

“There is no need to load the entire Java stack to run an application – just the runtime services it actually requires. OSGi therefore enables a more dynamic, less constricted Java.”

The JCP basically lost this war, and now OSGi is supported by every major app server vendor. It is also the key technology used by all of the enterprise service bus (ESB) players.

Beyond the Java IDE

One of the most enthusiastic backers of OSGi has been the Eclipse Foundation, which successfully wrenched control of great swathes of land from Sun in an earlier putsch. IBM led the initial Eclipse uprising in 2001, but without popular support it would have been nothing. Eclipse became how tools integration is done. Implementation beat specification. Now Eclipse is, quite simply, how Java tools are built. Eclipse today though goes far beyond IDEs, and OSGi underpins its runtime ambitions. If you’re a Java person and haven’t heard of Equinox yet… you will.

A Jetty for Web Apps

Talking of Eclipse, something I noticed last week is that Jetty, which recently became an Eclipse project, is popping up in some unexpectedly cool places. Jetty is the new smallness, and therefore the new hotness- the most embeddable app server of the moment. Less cludge means more productivity. Focus on the app not shaving the yak.

GitHub is a popular Software as a Service platform for distributed source code management. It is where the Ruby On Rails community lives. You want find libraries for building web apps? These days Ruby is the first language to check. GitHub is the first place. Last week came the announce of GitHub:FI, a behind the firewall version of the hosted platfrom- it’s based on JRuby running on Jetty. It is also used in the Yahoo Hadoop Cluster.

Meanwhile Java is evidently hot at Google, not something you would have bet on.

Java Syntax Not Dead Shocker

Google’s Android mobile platform SDK- is effectively a forked implementation of the Java 2 Mobile Edition spec. But Google doesn’t call it Java, so apparently it has no legal exposure. Stefano explains:

Android uses the syntax of the Java platform (the Java “language”, if you wish, which is enough to make java programmers feel at home and IDEs to support the editing smoothly) and the java SE class library but not the Java bytecode or the Java virtual machine to execute it on the phone (and, note, Android’s implementation of the Java SE class library is, indeed, Apache Harmony’s!) The trick is that Google doesn’t claim that Android is a Java platform, although it can run some programs written with the Java language and against some derived version of the Java class library.

Google App Engine Java Services – run on Jetty

Google Widget Toolkit – are being ported to Jetty

What all this amounts to is that Google is now a serious player in Java. But its evidently not a big fan of the JCP. Could we see a future lawsuit brought by Oracle against Google? I don’t think its beyond the realms of possibility. What’s old is new again. As has been pointed out, Eric Schmidt, now Google Chairman, was the guy that signed the original Java licensing deal with Microsoft before things went sour… what goes around may come around.

And Then There Were Three

It seems to me the future of Java could be fought out between IBM, Oracle and Google. There are some obvious wildcards- SpringSource has arguably been the most important player in Enterprise Java apis for the last couple of years – the strapline says it all Eliminating Enterprise Java Complexity. IBM, Oracle, BEA all now support the Spring Framework. SpringSource CEO Rod Johnson will definitely have a say in the future of Java. As will Red Hat.

But IBM and Oracle are the leviathans, the companies making serious money from Java. They have the most to lose and the most to gain. While Google- has developer mindshare like noone else right now. The new JavaOne- that’s looking like Google I/O.

Java isn’t dead though, any more than SOA is.

I started this post on a Friday afternoon – always risk for any project. Chances are it will need some cleaning up on Monday morning. But I wanted to give you, dear reader, something to sink your teeth into.

Pretty much every organisation mentioned in this piece except Google is a RedMonk client.

Categories: Uncategorized.

Comment Feed

9 Responses

  1. From JavaOne to Java 2.0: Java is Dead, Long Live Java http://bit.ly/YGmKH a work in progress, i would love your thoughts. peace out!
    This comment was originally posted on Twitter

  2. @monkchips Great Blog! “#Java is Dead, Long Live Java” http://tr.im/oiff
    This comment was originally posted on Twitter

  3. nice analysis from @monkchips about Java and Oracle http://twurl.nl/o3ahmn
    This comment was originally posted on Twitter

  4. Nice analysis James.

    How SAP responds to Oracle’s control of Java will also be interesting. I also think the JavaME licensees will be watching closely.

    Ian

  5. Hi James. One quick comment. You write:

    >>
    Rather than adopting the Sun and Java Community Process (JCP) sponsored JSR 277 specification for Java class modularity Glassfish went with OSGi. That is, even Sun’s products were “forking Java” by 2008.
    >>

    Actually, JSR 277 was not an option because the spec was in-flight and its release was dependent on Java SE 7. Since we needed a solution _then_, we needed something that would work on Java SE 6 and we wanted to reduce risks, what we did was use OSGi under our HK2 layer. We also stated we would align with whatever modular solution the Java SE 7 team would reach.

    I believe we made the right call; GF supports OSGi very well and, by making the decision then, we were able to move full-speed on the hard details of modularizing the services and containers, plus incorporating the Java EE 6 specs.

    • thanks for the clarification eduardo. as you say the spec was “in flight”. but modularity couldn’t wait. the call was absolutely – glassfish is the model of a modern app server.

      James GovernorJune 21, 2009 @ 12:47 pmReply
  6. Just reading ‘From JavaOne to Java 2.0: Java is Dead, Long Live Java’ at http://tiny.cc/rEUyo Let’s see what’s beyond Java …
    This comment was originally posted on Twitter

  7. “From JavaOne to Java 2.0: Java is Dead, Long Live Java” http://bit.ly/YGmKH James Governor’s take on the state of Java post JavaOne
    This comment was originally posted on Twitter



Some HTML is OK

or, reply to this post via trackback.

Continuing the Discussion

  1. […] the kind of lissome accounting us analysts get all giddy over. My esteemed colleagues Stephen and James were there the first part of the week and tended to the real work of talking at Community Day and […]