Published on ONJava.com (http://www.onjava.com/)
 See this if you're having trouble printing code examples

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.

Beyond the Sun

2006: BD-J makes a splash as part of Blu-Ray
2007: If Blu-Ray crashes and burns, will it take BD-J with it?

One novel use of Java ME is to provide the interactivity platform of the Blu-Ray Disc standard, one of two competing formats for high-definition movie systems (the other being HD-DVD). The standard includes the Java-based "BD-J" environment, which marries Java ME with some APIs borrowed from interactive television, to provide highly interactive menus and other potentially novel content, including network access from movie discs. Blu-Ray backers point out that the standard needs more compelling interactivity than is provided by DVDs as a distinguishing feature to help the format succeed; just having a clearer picture isn't enough to get people to switch.

But will it work? Blu-Ray's main proponent, Sony, has had a miserable track record in the press recently, between its rootkit and exploding battery fiascoes. Making Blu-Ray part of the PlayStation 3 was meant to be a boost to the standard, but instead it may actually be hurting the PS3, as gamers blame Blu-Ray for increasing the price and slowing production of the PS3. Worse for BD-J, Sony's first standalone Blu-Ray player doesn't actually support BD-J , with Sony saying that BD-J functionality will be provided in a 2007 firmware update.

Earlier this year, your editor went to a JavaOne session on Blu-Ray in hopes of getting information on developing for BD-J, and came away deeply disappointed. Now that Blu-Ray's presumed success is no longer a fait accompli, the question of whether developers can get a BD-J SDK without paying enormous license fees may not even matter.

2006: Eclipse Callisto offers ten simultaneous releases
2007: What's succeeding other than the IDE?

All indications are that the Eclipse IDE remains the top choice for Java development. But Eclipse is much more than an IDE. The Eclipse developers reminded everyone of that with this summer's Callisto release, the simultaneous drop of ten different Eclipse foundation projects.

Having said that, it remains to be seen just how much success Eclipse can muster beyond the IDE. The building blocks of Eclipse can be used to create rich client applications, in the form of the Rich Client Platform (RCP), but it's not clear how many developers have adopted this model. Eclipse's Standard Widget Toolkit (SWT) was supposed to be the answer to the problems of Swing, but after years of development, it seems as common in the wild as Swing--that is to say, not very. The rival widget toolkits can each claim credit for one IDE (Eclipse and NetBeans), one file-sharing program (Azareus and LimeWire), and not much else. Will 2007 be the year SWT lands on the desktop in a big way, or are it and Swing big ducks in a small pond?

2006: Google releases GWT
2007: Is GWT the new face of Ajax?

Introduced at JavaOne 2006, Google Web Toolkit offers an audacious and unexpected approach to writing Ajax applications: you write Java code with UI objects not unlike those of the Swing and SWT frameworks, and GWT will compile it into client-side JavaScript, handling all the various browser compatibility miseries for you. There's immense potential to spare developers from low-level JavaScript debugging, but it will be interesting to see if developers are willing to cede so much control to their framework, or if they will insist on hand-rolling their own client and server code.

2006: Google deprecates SOAP search API
2007: Is this the beginning of the end of SOAP?

Just this week, InfoQ noted Google's deprecation of its SOAP Search API, in favor of an Ajax-oriented alternative that's better suited for client-side use than server-side. O'Reilly Radar blogger Brady Forrest called it a "a unilateral move that is going to alienate at least some of the Google dev community and lead to defections to other services," and worried about the effect on web services as a whole, since it was in many ways the canonical web service. Steve Loughran goes further, calling it The end of SOAP, and shedding few tears: "it won't happen at once, it won't be overnight, but one day SOAP will be over. We will look back and wonder 'what were we thinking?'. It will be up there with ActiveX, EJB2, and other things that we will describe as mistakes that should never have made it past the powerpoint stage."


2006: JSR 306 proposed to reform JCP
2007: Can the JCP make all the people happy?

JCP 306 was approved in August, under the daunting title "Towards a new version of the JCP." Among its goals are improving the transparency of the Java Community Process, improving the involvement of individuals, and optimizing the duration of JSRs. Also in its charter are possible changes to improve working with other standards bodies, working with non-Java implementations, easing migration of existing technology into JSRs, and making TCK and licensing information available upon conclusion of a JSR.

The expert group's early draft review was tentatively scheduled for this month, with a public draft review in February 2007, a final draft in April, and the final approval ballot in May. This proposal needs to pass both the SE/EE and ME executive committees, and it's sure to get a close look, particularly following the criticism JSR 277 received from OSGi and others who've worked on problems similar to 277's "Java Module System."

2006: Java book sales continue to decline
2007: What's declining, Java or books?

In his most recent survey of the State of the Computer Book Market, Tim O'Reilly notes the continued slide of Java book sales, down 15 percent in the last run of the stats. He writes:

The decline of Java book sales has accelerated, while C# books have continued their steady increase. When you aggregate books on both C# ".Net Languages" (books that cover both C# and VB.Net), the C# book market is now about 12% larger than Java. (Of course, some of those .Net Languages book purchasers could be buying them for their coverage of VB.)

Perhaps it's not surprising that 2005 would have moved more books in support of the language changes in Java SE 5, and that 2006 would be slower with no such changes in SE 6. That said, the Java book market is an odd beast; few titles can be relevant to all Java programmers, and the various topic niches and programming frameworks may be too small to support books on them. How many Java web frameworks are there, and how many have enough of a professional following to sell a lot of $40 books? It's possible that the future of Java content may be in different forms, like the O'Reilly Short Cuts PDFs, or online articles like those here on ONJava and java.net.

Your Turn

So that's a brief overview of some of the 2006's most prominent Java happenings, and what you might look for in 2007. But what do you think? What's happening in Java from your point of view, and what should we be looking at next year? What did we cover too much on ONJava this year, and what would you rather see covered more in 2007?

To finish out this year-ender, let's hand it over to you, the readership. In the Comments section below, please let us know what matters to you as Java developers, and how ONJava can help you make the most of the opportunities that Java provides.

But one last thing before the comment block begins: thanks for reading this year. See you in 2007.

Chris Adamson is an author, editor, and developer specializing in iPhone and Mac.

Return to ONJava.com.

Copyright © 2009 O'Reilly Media, Inc.