ONJava.com -- The Independent Source for Enterprise Java
oreilly.comSafari Books Online.Conferences.


AddThis Social Bookmark Button

Review/Preview: 2006 and 2007 in Java

by Chris Adamson

Unlike previous years, 2006 has been a defining year for Java, marking fundamental change for what remains, by many objective measures, today's most popular programming language. Most critical to the fate of Java is Sun's decision to release its implementation of Java under terms of the GPL, a process that is well underway today with the release of the HotSpot VM, javac compiler, and a GPL Java ME implementation (Java EE was open-sourced last year as the GlassFish project). The SE pieces aren't enough to comprise a complete Java platform yet--that will happen next year when the class libraries are open-sourced. Still, the progress is a lot more than almost anyone would ever have predicted a year ago, and virtually nobody expected Sun to choose GPL for its open source license.

But what happens next? That's the big question. As with a lot of this year's events, it's not obvious what this move will lead to, rife as it surely is with unintended consequences. So for this year's "2006 In Review" article, we're taking a different approach: we're listing some of the major developments and pointing out what to look for in 2007 as a results of those events.

Open Source Java

2006: Sun open-sources its Java VM and compiler under the GPLv2
2007: Watch for class libraries... and forks

The GPL release of the Java compiler and VM shows Sun is serious about open-sourcing Java, but it's too soon to see what the results will be. For one thing, the released code is basically a very early Java SE 7, as Sun didn't want the open source work to interfere with the release of Java SE 6, which happened earlier in December. Along with being a pre-spec VM, the release also lacks the class libraries that would be needed to bring up a useful Java environment.

One of the challenges in providing the class libraries is having to search millions of lines of code for encumbrances, code that Sun licensed to use in Java and that it doesn't have the rights to GPL. Some of these may have suitable drop-in replacements from the open source world, but sooner or later, it's inevitable that there'll be some things that Sun will need to relicense, rewrite, or omit.

The big question beyond this is what people do with Java now that it's GPL. Beyond solving the political issues involved with including Sun's JVM with certain Linux distros, and getting the JVM ported to platforms that Sun itself isn't interested enough to do its own versions for, there's the question of what unpredictable things people will do with the bits. Does HotSpot's dynamic runtime compiler offer something to other languages' runtime? Will developers fork the language itself by hacking the compiler to add or remove language features? The result can't be called Java, but so what? Maybe Java could be used for domain-specific languages, in which case there'd be no desire to call the resulting variant "Java" or anything that starts with a "J."

2006: Sun creates and promotes Distro License for Java
2007: Does it matter anymore?

If you're a Linux distro, it should be obvious by now that Sun is totally smitten with you. Even before the surprising GPL-ing of Java, Sun was making overtures to the Ubuntus and Debians of the world with the Distro License for Java, which lets the platform developers package Java SE in a form that makes sense for their platform, so users can get a JVM with something like an apt-get rather than having to do some sort of hand install.

Of course, with the GPL release of Java, the need for the DLJ would seemingly go away; any changes necessary to the JVM, its class libraries, or the form of its release can readily be made, provided those changes are themselves published under the GPL--and GPL compatibility was the whole issue with most of the Linux distros anyway. So, on the surface, the DLJ would appear to be necessary only until GPL Java is itself ready to be stuffed into a .dpkg. But how long will that be?

The Java Platforms

2006: Java SE 6 released
2007: When will developers adopt it?

A little behind its original schedule, Java SE 6 arrived in mid-December. The new version offers a smattering of new APIs including XML Digital Signature, updates to essential APIs like JDBC 4.0 and JAXB 2.0, a re-architected graphics-rendering pipeline, greater fidelity in Swing's Windows and GTK look-and-feels, and more.

But given the deliberation with which many Java developers, deployers, and users adopt new versions of Java (anecdotally, the nearly five-year-old Java 1.4 still seems to be in wide use), what about SE 6 will get people to switch? Unless you need some specific feature, say, JDBC 4.0's SQLXML data type, will it be worth installing a whole new JVM, and a "dot zero" release at that? Performance improvements--particularly for desktop apps--notwithstanding, we may be well into 2007 before SE 6 is assumed to be the default version.

2006: Java SE 6 runs languages other than Java
2007: What languages will you be running on the JVM?

Perhaps the most interesting change you can point to is SE 6's built-in support for scripting languages. The new javax.script APIs allow you to instantiate and use scripting language engines in Java, and to exchange data between the language and Java. Java SE 6 provides built-in support for JavaScript (via the Rhino engine), and more languages are certain to be added by third parties.

The obvious "next language" may well be Ruby, given that Sun hired the developers of JRuby in September. Not only does this elevate the status of Ruby within the Java world, but some have also noted that it has already sped up the JRuby release schedule.

The idea of running other languages on the JVM is nothing new, of course--Robert Tolksdorf's list shows over 200 language options for the JVM--but Ruby is special given the buzz surrounding Ruby and the Rails framework as a rival to Java for building enterprise web applications. This was the major theme of Bruce Tate's book Beyond Java. But another often overlooked point of Tate's book was the idea that the JVM solves so many essential problems, such as security and cross-platform compatibility, that any successor to Java would likely need to run on the JVM. In other words, nobody wants to start over with an insecure language or framework that ties you to one platform.

Is Sun co-opting the Ruby buzz, or picking favorites? Maybe a little of both, but there's a deeper story here; as much as pundits talk about Ruby/Rails' potential to steal an audience of Java developers, it's clear that it's also luring developers away from other scripting languages, such as Perl and PHP.

2006: JDK 7 development begins
2007: The closures argument comes to a head

JDK 7 development is already underway, although it will be some time before a set of features for this list comes together. Surely the most debated language feature on the JDK 7 table is the proposal to add closures to the Java language.

In essence, there are really two arguments here. The first is whether closures are needed at all, or whether the increase in complexity outweighs the benefits closures would provide in specific cases. Given that some of what closures provide is already accomplished by anonymous inner classes, the specific pain points that closures would alleviate may simply not justify another language structure. The second argument is about the specific syntax of the closure proposal, and whether its apparent desire for compactness may make Java closures unnecessarily hard to read.

2006: Java EE 5 released
2007: Will EJB 3 win back developers?

Java EE 5 was released this summer and with it, EJB 3.0, the profound reworking of the much-maligned enterprise object framework.

The story to watch for in 2007 is whether EJB 3.0 can win back the developers who abandoned the pedantic EJB 2.x approach in favor of simpler approaches to business logic (Spring) and persistence (Hibernate), or if that audience has found what it needs in the alternative frameworks. And if EJB can't win them back, is that really bad for anyone other than Sun and the various EE licensees?

2006: Java ME still on every phone
2007: Does a GPL ME change anything?

Java ME seems to attract the least notice or attention of the three major Java platforms, even though its distribution on mobile phones would presumably make it more ubiquitous than SE or EE. Some of that, surely, comes from application distribution problems caused by the difficulty of working through mobile service providers, at least in the U.S. So while there's now an open source CLDC/MIDP platform, it's an open question as to what anyone will do with it. While manufacturers may choose to stick with current licensing arrangements, a GPL ME might be ideal for upstarts in other small device spaces.

Pages: 1, 2

Next Pagearrow