Sun Creates Feature Removal Process for the Java Platform
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.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.
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.
Now that a formal process for removal has been created what sections of the Java Platform do you think should be considered?
remove it all - use a kernel architecture. :)
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.
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:
Hope you haven't laid off too many of your attorneys, Sun. You're going to need them.
appropriate suggestion from related vendor content
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...
Re: remove it all - use a kernel architecture. :)
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 ;-)...
Prime Candidates for Removal
2) Swing and AWT! Why force JVMs that target server platforms to implement a GUI library?