VMware Infrastructure 3 Book Excerpt and Author Interview
VMware Infrastructure 3: Advanced Technical Design Guide and Advanced Operations Guide provides a wealth of practical insights into setting up virtualization in todays corporate environments.
Tracking change and innovation in the enterprise software development community
Posted by Scott Delap on Aug 30, 2006 04:00 PM
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.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?
Real-World SOA: Definition, Implementation and Use of SOA with CentraSite
Ensuring SOA success with effective, automated control throughout the lifecycle
If SOA was the answer, what was the problem? (blog)
SOA Governance: Rule your SOA Whitepaper
The Key to SOA Governance: Understanding the Essence of Business
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.
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.
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.
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...
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 ;-)...
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?
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! :)
VMware Infrastructure 3: Advanced Technical Design Guide and Advanced Operations Guide provides a wealth of practical insights into setting up virtualization in todays corporate environments.
Can a system that is so large it cannot be comprehended be "designed" in a conventional sense? The foundations of computing are about to change. In this talk, Richard P. Gabriel explores why and how.
Ruby 1.9's Fibers and non-blocking I/O are getting more attention - we talked to Mohammad A. Ali of the NeverBlock project and Tony Arcieri of the Revactor project.
Tim Mackinnon talks about the aspirations behind the Agile principles and practices, the desire to become efficient, to write quality code which does not end up being thrown away.
Brian Goetz discusses the difficulties of creating multithreaded programs correctly, incorrect synchronization, race conditions, deadlock, STM, concurrency, alternatives to threads, Erlang, Scala.
Often the hardest part of changing technologies is language syntax differences. This new article provides Java developers with a transition guide to Actionscript which forms the foundation of Flex.
Neal Ford talks about having multiple languages running on one of the two major platforms: Java and .NET. He also presents the advantages offered by Ruby compared to static languages like Java or C#.
David Anderson talks about the history of Agile, the current status of it and his vision for the future. The role of Agile consists in finding ways to implement its principles.
7 comments
Reply