Sun Creates Feature Removal Process for the Java Platform

No feature has ever been removed from the Java SE platform, and the stand policy has been that no feature ever will be removed. While this has been good for backwards compatibility, the download size of the JRE has continued to grow. JSR 270 takes the first step to reversing this trend with the definition of a set of guidelines to govern removal of features from the Java SE platform. In summary they are as follows:

Scope - The feature removal process should only be applied against large features, on the scale of entire packages or subsystems. Less-costly ways should be applied to smaller units that are not little-used or fundamentally-broken such as deprecation or appropriate documentation.

Process - Removing a feature is a two step process that involves two feature releases and, therefore, two Umbrella Expert Groups (UEGs). The UEG for release N of the platform may decide to propose that a feature be removed. This will cause the specification for that release to indicate that the feature may be removed in future releases. The UEG for release N+1 gets to make the actual decision as to whether the feature is removed from that release, retained as a required component, or left in the “proposed removal” state for the next UEG to decide ... Each UEG involved in this process is expected to undertake widespread consultation with the Java SE community, and especially with those using current releases in production settings, in order to ensure that the community supports the proposed feature removal ... Once a feature has been proposed for removal, but before it is actually made optional, platform implementors are strongly encouraged to provide mechanical assistance to developers, e.g., in the form of compile-time warnings, that the feature may be removed in the next release.

Result - 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 Java SE platform into an optional component. As such its specification is still part of the Java SE Platform specification but it is identified, in a very prominent way, as an optional feature that might not be available in all platform implementations.

A particular implementation of the Java SE platform may omit an optional feature or it may still contain the feature, at the discretion of the implementor. A platform implementor may choose to ship an implementation of an optional feature in some alternate form, e.g., as a separate jar co-packaged with the platform implementation or available for download on the web. If an implementor ships implementations of the Java SE platform for several different target operating-system/hardware combinations then the implementor is free to include the feature for some targets but omit it for others.

An optional feature may be further unbundled from the Java SE platform if its Maintenance Lead commits to providing a standalone TCK. This would make it possible to create implementations of optional features that are independent of any particular platform implementation.

In any case, the Java SE TCK will continue to contain the tests for removed features after they become optional. Implementations of optional features will be required to pass these tests, regardless of the form in which they are delivered.

The first feature proposed to undergo this process, javax.midi.sound, is listed in JSR 270. Mark Reinhold, Chief Engineer for the Java Platform SE, discusses the new guidelines on his blog. He mentions that another popular candidate for removal was CORBA, but that a number of existing client applications depend upon RMI-IIOP which is tightly coupled with the existing CORBA API's.

Now that a formal process for removal has been created what sections of the Java Platform do you think should be considered?