Sun's Disagreement With Apache Overshadows Java 7 Announcement

Posted by Charles Humble on Mar 31, 2009

Sections

Development,

Architecture & Design

Topics

JCP Standards ,

Programming ,

Java

Tags

Java SE ,

JCP

Sun Microsystems' Mark Reinhold has published an updated schedule for JDK 7 along with a list of the approved features on the OpenJDK website. The current build is milestone 2 which includes the new Garbage First Garbage Collector and I/O APIs [JSR 203]. Milestone 3, expected in time for the JavaOne conference in May, will add VM support for dynamically typed languages via the invokedynamic bytecode instruction [JSR 292]. Other notable features planned for Java 7 include a forward port of Java 6 update 10 into the OpenJDK (targeted at milestone 4), the currently dormant Swing Application Framework [JSR 296], expected in milestone 5 in the autumn, and another attempt at standardising modulisation through JSR 294 and Project Jigsaw. Notably absent from the current roadmap are the new Date and Time API [JSR 310], Beans Validation [JSR 303] and Beans Binding [JSR 295].

 The small language changes initiative, Project Coin, has also seen a large number of proposals with Joseph Darcy highlighting six strong contenders for inclusion in Java 7 on his blog:

1. Automatic Resource Management. Submitted by Joshua Bloch, an ARM block is a form of the try statement that declares one or more resources which are then limited to that statement. When the statement completes, whether normally or abruptly, all of its resources are closed automatically. This removes the need for the manual closing of resources, which has proven very error prone in practice. Two thirds of the uses of the close method in the JDK itself are implemented incorrectly according to Bloch.
2. Elvis and other null-safe operators. Submitted by Stephen Colebourne from an original suggestion of Neal Gafter's, this aims to fix some of the common problems with NullPointerExceptions, making it possible to omit null checks on objects.
3. Improved Exception Handling. Submitted by Neal Gafter, this proposal includes catch blocks which handle multiple exception types and improved checking of re-thrown exceptions.
4. Improved Type Inference for Generic Instance Creation. Submitted by Jeremy Manson, this proposal addresses the addition of limited type inference for class instance creation expressions. For example instead of writing:
   Map<String, List<String>> anagrams = new HashMap<String, List<String>>();
   You could write:
   Map<String, List<String>> anagrams = new HashMap<>();
5. Simplified Varargs Method Invocation. Submitted by Bob Lee, this proposal is a compiler change for warnings which are issued when a method combines varargs with non-reifiable array types. The change moves the warning from the call site to the method declaration.
6. Strings in switch statements. Joseph Darcy’s proposal adds support for strings to the switch statement.

Sun’s JDK for Java 7 will be their first to be based on OpenJDK, though their implementation will still depend on some closed source components. It also continues a change in the way Sun develops its Java products, with increasing numbers being developed without a JSR, then standardised when complete. Project Jigsaw, JavaFX, and Java SE 7 are all being developed this way. Mark Reinhold describes it like this:

"The JDK 7 Project is creating a prototype of what might—or might not—wind up in the Java SE 7 Platform Specification. When the SE 7 Platform JSR is submitted then the features under development in JDK 7 will be proposed for inclusion therein, except for those that are VM-level or implementation-specific.” 

This combination of the OpenJDK project with a transparent feature set and schedule for Java 7 is a much more open process than we've seen in previous revisions to the language, but Apache's Stephen Colebourne is deeply concerned by the change, arguing that there could be no official specification for Java 7, instead only a JDK implemented by Sun:

"All the evidence I see is that Java SE is no longer an open standard and the next release will be JDK 7, not Java 7. That is something that should matter to all of us who care about the Java eco-system.

 

After all, if Sun can get away with making Java SE not an open standard, then why not Java EE, or Servlets or JMS? It's time to stand up and be counted and demand our open standard back!"

In a follow-up post Colebourne uses minutes from the JCP Executive Committee meetings to support his argument, claiming that the reason for the process change is connected to Sun's long running dispute with Apache over the changes in licensing terms for the Java Compatibility Kit (JCK) wanted by Apache for their Harmony project.

"...from the September 2008 meeting, there is distinct evidence (but not proof) that Sun feels unable to get a Java SE 7 JSR passed until the Harmony dispute is resolved. We can also note the difference in tone between April 2008 and June 2008, where a Java SE 7 platform JSR went from 'soon' to 'no immediate plans', and Sun's focus became clearer around using Open JDK instead of a JSR."

Colebourne’s argument is supported by Neil Bartlett. Using rumours of Sun’s pending acquisition as a reason for using OSGi instead of Project Jigsaw, he argues that any Sun-led initiative not supported by a JSR can be killed off the moment Sun is acquired:

"Sun is unlikely still to exist in its current form by this time next year. Whether it is eaten whole by IBM or torn in half and shared between HP and Oracle, or any of the other rumored outcomes, a promise from Sun to support Jigsaw is completely worthless. This is especially true because Jigsaw is in direct opposition to the commercial needs of all the potential acquirers. If IBM gets Java, it will kill Jigsaw, I guarantee it. Ditto Oracle. By choosing to build Jigsaw outside of a JSR and in opposition to an established industry standard, Sun has exposed its customers to substantial commercial risk."

So far Apache's tactic of voting against all JSRs whilst their dispute with Sun continues has had no real impact on the development of Java, since they've been able to garner only limited support for the tactic from other JCP members. This is presumably because other JSRs are not affected by the same licensing terms. However Java SE 7 would be directly affected. If Colebourne is correct in his conjecture that Sun has changed the way Java 7 is being developed because of Apache's tactics, then the combination of these tactics with intransigence on both sides will begin to do tremendous damage to both Java and the JCP.

 

1. Back to top

   Correction: I am NOT an "OSGi spokesman"

   by Neil Bartlett

   I am merely an enthusiastic user of the technology.
   
   Regards
   Neil

   Reply

2. Back to top

   Re: Correction: I am NOT an

   by Charles Humble

   Neil - my apologies. I've amended the post accordingly.
   Charles

   Reply

• Older >