Perhaps the most significant recent change to the JSR 270 specification is the definition—and first application—of a policy for removing existing features. Herewith a bit about the motivation and the details, and why you might not be able to play MIDI sound files out-of-the-box on a future version of the platform.

Why?The Java SE Platform has grown monotonically since it was first released. No feature has ever been removed, and the standing policy has been that no feature ever will be removed.

This policy has had its benefits, chief among them the fact that it’s a cornerstone of the platform’s strong commitment to binary compatibility. If an application is built on release N then it will run on release N+1. (Modulo bugs, of course.)

As the platform has matured, however, some of the disadvantages of this policy have gradually become evident. Chief among these are the facts that both the conceptual complexity of the platform and the size of minimal Java Runtime Environment (JRE) download bundles have, in turn, also grown monotonically.

How? The details are in the Public Review draft of the JSR 270 specification, but basically there are two steps:

1. The Umbrella Expert Group (UEG) for release N of the platform decides to propose that a particular feature be removed. The specification for that release documents the proposal.
2. The UEG for release N+1 decides whether to remove the feature from that release, retain it as a required component, or leave it in the “proposed removal” state for the next UEG to decide.

It’s generally expected that UEG N+1 will follow through on the proposal made by UEG N unless new information indicates that the Java community would be better served by one of the alternatives. If UEG N+1 decides not to remove the feature but also decides not to retain the feature as a required component then UEG N+2, and so on, will be faced with the same three-way decision.

The result of successfully applying this policy to a feature is not the actual deletion of the feature but rather the conversion of the feature from a required component of the platform into an optional component. Its specification remains part of the Java SE Platform Specification, and its tests remain in the TCK, but it’s prominently identified as an optional feature that might not be available in all platform implementations.

What? This process is only intended to be applied to large features, on the scale of entire packages or subsystems. It’s not intended to be applied to one or a few classes, nor to specific class members (methods, fields, etc). There are almost always less-costly ways to deal with little-used or fundamentally-broken API elements at this smaller scale, e.g., deprecation or appropriate documentation.

In other words, we’re not going to go around deleting random deprecated methods. The potential breakage just isn’t worth the cost.

What now? The Public Review draft of the JSR 270 specification proposes the removal of the javax.sound.midi package in a future release of the platform. This package isn’t often used and typical implementations of it require a large data file, about half a megabyte in size, which is a significant component of minimal Java Runtime Environment (JRE) download bundles.

This doesn’t mean that the MIDI package will be removed from JavaSE 6. This proposal is merely the first step in the two-step process described above. The MIDI package might be removed in a future release of the platform, but whether it is actually removed, and in which release, is a decision for future expert groups.

Why aren’t you removing … The JSR 270 EG discussed several other candidates for removal, but we only reached consensus on the MIDI package.

A particularly popular candidate was CORBA, but it turns out that lots of existing client applications depend upon the RMI-IIOP protocol and it doesn’t appear possible to tease out RMI-IIOP from the rest of the CORBA APIs. Deciding to remove CORBA might be easier once the platform has a robust module system so that the CORBA packages can be downloaded as needed.