Sun Creates Feature Removal Process for the Java Platform

Posted by Scott Delap on Aug 30, 2006

Sections

Development,

Enterprise Architecture

Topics

Governance ,

Java ,

JCP Standards

Tags

Java SE

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?

1. Back to top

   remove it all - use a kernel architecture. :)

   by Floyd Marinescu

   It is VERY encouraging to see Sun talking about actually removing features. After all the community anger about bloat in Java compeitition from other supposedly "lightweight" (and feature lacking) competitors - it's great to see the option of removing features becoming a possibility.
   
   Removing Corba is a great idea. On his blog Mark mentioned that it "might be easier once the platform has a robust module system so that the CORBA packages can be downloaded as needed." Well if we are going to take a kernel with optional download approach to Java, then that gives us the possibility to remove even more and allow different parts of Java to evolve separately.

   Reply

2. Back to top

   Asinine

   by Corby Page

   This is thoroughly outrageous. Every enterprise Java application that I have developed over the last five years plays a MIDI rendition of Bon Jovi's "You Give Love A Bad Name." It is an essential part of the end-user experience. If you don't understand how important user experience is, talk to the AJAX fanatics.
   
   By deprecating MIDI to an optional package, you will be complicating the upgrade process for mission-critical energy applications. How's it going to feel when you are paying ten cents more at the pump because of:
   
   

   java.lang.NoClassDefFoundError: javax.sound.midi.Sequencer

   
   
   Hope you haven't laid off too many of your attorneys, Sun. You're going to need them.

   Reply

3. Back to top

   appropriate suggestion from related vendor content

   by Tim Clark

   As I look at the page the top link in the RelatedVendorContent section is "Get Started with Java Server Faces" - I think that would be an excellent place to start the removal process.

   Reply

4. Back to top

   Re: Asinine

   by Mike Keith

   Well, I think they should be flogged if they don't ditch *all* of the omg stuff along with the CORBA ;-).
   
   While this whole thing is not a bad idea, it really doesn't solve the deprecation problems. Java is hopelessly cluttered with deprecated APIs that are never going to go away, and there is still no process or strategy for cleaning it up.
   
   In terms of stuff I am never going to use, the printing package is next on my list. I fully recognize, though, that there is going to be someone out there that would be absolutely appalled if it were to go away. Reminds me of when James Gosling, when he was asked which Java package he wouldn't mind going away, said that he never used JDBC...

   Reply

5. Back to top

   Re: remove it all - use a kernel architecture. :)

   by Alef Arendsen

   
   Well if we are going to take a kernel with optional download approach to Java, then that gives us the possibility to remove even more and allow different parts of Java to evolve separately.

   
   
   Hmmmm, let the complexity of dependency management in Java also affect the platform itself... Don't think this is such a good idea ;-)...

   Reply

6. Back to top

   Prime Candidates for Removal

   by Neil Bartlett

   1) JavaDB. Yes, I know it's only just gone in...
   2) Swing and AWT! Why force JVMs that target server platforms to implement a GUI library?

   Reply

7. Back to top

   Re: Asinine

   by Floyd Marinescu

   Reminds me of when James Gosling, when he was asked which Java package he wouldn't mind going away, said that he never used JDBC...

   Classic quote! :)

   Reply

• Older >