InfoQ

InfoQ

News

My Bookmarks

Login or Register to enable bookmarks for unlimited time.

The content has been bookmarked!

There was an error bookmarking this content! Please retry.

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?

remove it all - use a kernel architecture. :) by Floyd Marinescu Posted
Re: remove it all - use a kernel architecture. :) by Alef Arendsen Posted
Asinine by Corby Page Posted
Re: Asinine by Mike Keith Posted
Re: Asinine by Floyd Marinescu Posted
appropriate suggestion from related vendor content by Tim Clark Posted
Prime Candidates for Removal by Neil Bartlett Posted
  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.

  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.

  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.

  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...

  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 ;-)...

  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?

  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! :)

Educational Content

New-age Transactional Systems - Not Your Grandpa's OLTP

John Hugg discusses high volume transaction processing applications with high and low frequency profiles, and how VoltDB can be used for that purpose.

Cool Code

Kevlin Henney examines code samples to see what can be learned from them starting from the premise that one won’t write great code unless he knows how to read it.

Collaboration: At the Extremities of Extreme

Jason Ayers share the observations he made watching a team of developers collaborating in real time on the same code base, pushing XP, pair programming and continuous integration to their extremes.

Yesod Web Framework

Michael Snoyman presents Yesod, a web framework written in Haskell and containing a web server, templating, ORM, libraries (templating, gravatar, etc.).

Transactions without Transactions

Richard Kreuter and Kyle Banker on how to avoid classical RDBMS transactional systems by using compensation mechanisms, transactional messaging or transactional procedures.

Attila Szegedi on JVM and GC Performance Tuning at Twitter

Attila Szegedi talks about performance tuning Java and Scala programs at Twitter: how to approach GC problems, the importance of asynchronous I/O, when to use MySQL/Cassandra/Redis, and much more.

10 tips on how to prevent business value risk

One category of risk that project teams need to ensure they address is business value failure – delivering a product that fails to provide value for the business investor.

Interview: Software Systems Architecture: Working With Stakeholders Using Viewpoints and Perspectives

InfoQ spoke to the authors of Software Systems Architecture on a couple of new topics, the System Context viewpoint and Agile, which have been added to the second edition.