Removing features from the Java SE platform

Perhaps the most significant recent change to the JSR 270 specification is the definition—and first application—of a policy for removing existing features. Herewith a bit about the motivation and the details, and why you might not be able to play MIDI sound files out-of-the-box on a future version of the platform.

Why?The Java SE Platform has grown monotonically since it was first released. No feature has ever been removed, and the standing policy has been that no feature ever will be removed.

This policy has had its benefits, chief among them the fact that it’s a cornerstone of the platform’s strong commitment to binary compatibility. If an application is built on release N then it will run on release N+1. (Modulo bugs, of course.)

As the platform has matured, however, some of the disadvantages of this policy have gradually become evident. Chief among these are the facts that both the conceptual complexity of the platform and the size of minimal Java Runtime Environment (JRE) download bundles have, in turn, also grown monotonically.

How? The details are in the Public Review draft of the JSR 270 specification, but basically there are two steps:

  1. The Umbrella Expert Group (UEG) for release N of the platform decides to propose that a particular feature be removed. The specification for that release documents the proposal.
  2. The UEG for release N+1 decides whether to remove the feature from that release, retain it as a required component, or leave it in the “proposed removal” state for the next UEG to decide.

It’s generally expected that UEG N+1 will follow through on the proposal made by UEG N unless new information indicates that the Java community would be better served by one of the alternatives. If UEG N+1 decides not to remove the feature but also decides not to retain the feature as a required component then UEG N+2, and so on, will be faced with the same three-way decision.

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 platform into an optional component. Its specification remains part of the Java SE Platform Specification, and its tests remain in the TCK, but it’s prominently identified as an optional feature that might not be available in all platform implementations.

What? This process is only intended to be applied to large features, on the scale of entire packages or subsystems. It’s not intended to be applied to one or a few classes, nor to specific class members (methods, fields, etc). There are almost always less-costly ways to deal with little-used or fundamentally-broken API elements at this smaller scale, e.g., deprecation or appropriate documentation.

In other words, we’re not going to go around deleting random deprecated methods. The potential breakage just isn’t worth the cost.

What now? The Public Review draft of the JSR 270 specification proposes the removal of the javax.sound.midi package in a future release of the platform. This package isn’t often used and typical implementations of it require a large data file, about half a megabyte in size, which is a significant component of minimal Java Runtime Environment (JRE) download bundles.

This doesn’t mean that the MIDI package will be removed from JavaSE 6. This proposal is merely the first step in the two-step process described above. The MIDI package might be removed in a future release of the platform, but whether it is actually removed, and in which release, is a decision for future expert groups.

Why aren’t you removing … The JSR 270 EG discussed several other candidates for removal, but we only reached consensus on the MIDI package.

A particularly popular candidate was CORBA, but it turns out that lots of existing client applications depend upon the RMI-IIOP protocol and it doesn’t appear possible to tease out RMI-IIOP from the rest of the CORBA APIs. Deciding to remove CORBA might be easier once the platform has a robust module system so that the CORBA packages can be downloaded as needed.

Comments:

MIDI... So eighties :) Reminds me of the Tetris games i used to play on Commodore.

Posted by Kirill on August 29, 2006 at 08:30 AM PDT #

Hi Mark - thanks for the heads up. Why not just remove the default GM MIDI Synthesizer provider instead of the full javax.sound.midi package?

Posted by Anthony Green on August 29, 2006 at 09:32 AM PDT #

Anthony: Whether the MIDI APIs are actually removed, or instead left behind but without an (acceptable) implementation, would make little difference to an application that relies upon these APIs today. One of these approaches might be preferable over the other for orthogonal reasons, but in either case such an application would fail miserably on a platform implementation that didn’t provide the needed functionality.

Posted by Mark Reinhold on August 29, 2006 at 02:25 PM PDT #

At first glance all I've got to say is "Thank god!" Java has accumulated a lot of API garbage over the years and it would be great to dump some of it. There are still 10,000 different ways to create a new Image in Java with minute differences between each one. We need some refactoring to improve the cohesion of the API. Just my 2 cents...

Posted by Gili on August 30, 2006 at 01:08 AM PDT #

Throw out Corba? Probably because of the Soap hype. But the arguments of this article are still valid:

http://www.xs4all.nl/~irmen/comp/CORBA_vs_SOAP.html

At least the Corba API should stay in the JDK so you could plug in JacORB.

Posted by Juergen Weber on August 30, 2006 at 01:24 AM PDT #

OSGi to the rescue. :)

Posted by BenY on August 30, 2006 at 04:20 AM PDT #

Mark, Anthony makes a good point, and so do you, but maybe the compromise is the oft-floated dynamic loading of API implementation modules. Rather than failing miserably, you just have to wait a little bit while the platform downloads an implementation. If a process for removing features can actually happen [[gasp!!]] then maybe shrinking the JRE by dynamic loading could happen, too. I'm totally cool with a separate version of the JRE/JDK that purposely never implements deprecated APIs. Would be good for "API-currentness" evaluation, and it could easily bow out and say, "Gosh, you need an old API, so I'll exit and load the full JRE or go get it if it's not there. There's got to be an easier way to get people to move forward and discourage the old APIs without forcing them to, and with the increasing frequency of releases and sheer number of new features on the table for consideration, something has to be done to trim the fat and allow a more dynamic, faster, smaller version of Java. I recommend that the issue be addressed sooner rather than later.

Posted by GerryG on August 30, 2006 at 04:39 AM PDT #

Mark: That's not quite right. Only the applications that depend on the GM Synth will fail if you remove that provider. There are plenty of applications that only depend on the API and maybe some of the other midi device and file reader/writer providers. If the main concern is the size of the GM Synth (which I'm sure is huge, and I'm guessing problematic to open-source), then just dump it from your distribution.

Posted by Anthony Green on August 30, 2006 at 06:37 AM PDT #

How about removing Swedish resource files from JRE? I guess there was / is someone from Sweden that invested some time in translating a lot of stuff, but Swedish is not \*that\* important compared to the other bundled languages. And what about all Lucida fonts - why are they in JRE? They take 1.97MB uncompressed...

Posted by Kirill on August 30, 2006 at 08:35 AM PDT #

In general, I'm very much for switching things to optional packages. But if I've built an app dependent on an optional feature (say, MIDI), how do I deploy it and be guaranteed that the user will have access to that feature in their JRE? I'm guessing we need some sort of auto-downloader whereby optional modules can be fetched as needed, but that's a seemingly big undertaking and pre-supposes that the JRE has an active Internet connection. Further, why not go the extra step of promoting classes or methods to 'optional status'. I'm thinking of something along the lines of what Hibernate did with org.hibernate.classic.Session vs org.hibernate.Session. If you want legacy behavior, declare yourself as using the class from a different (now optional) package. Not to start a rant, but when will we eliminate deprecated methods defined on an interface? I just love implementing an interface and having to provide an implementation for a deprecated method.

Posted by Jeffrey Bennett on August 30, 2006 at 09:45 AM PDT #

GerryG: Dynamically downloading and installing optional modules is definitely worth considering here, and it’s why I mentioned JSR 277 (Java Module System) above.

Posted by Mark Reinhold on August 30, 2006 at 03:00 PM PDT #

Ah, just happened to spot it in the last sentence. My eyes glazed over when you mentioned CORBA. :-)

Posted by GerryG on August 31, 2006 at 05:05 AM PDT #

Anthony: The problem with just dumping the GM synthesizer is that, as you point out, existing applications that depend upon it will fail. That’s a bad thing.

Strictly speaking the Java SE platform specification doesn’t require that an implementation of the MIDI API include a GM synth, but many—if not most—existing implementations do include one.

How many existing applications would break if we removed the GM synth from existing JREs but retained the MIDI API itself? If the answer is “most” then it might be better to remove the entire package rather than retain it in a way that could break existing applications.

This sort of question is exactly why the feature-removal process spans (at least) two feature releases. That increases the probability that the final decision to remove a feature will be informed by a broad sampling of community input.

Posted by Mark Reinhold on September 04, 2006 at 03:18 PM PDT #

Kirill: The Swedish resource files aren’t required by the platform specification, so Sun could remove them from its implementation at will without any regard to the JCP—though I imagine some of our customers in Sweden might not be very happy about it. In any case they don’t actually take up that much space (er, the files; I’m not sure about the Swedes), so removing them would hardly be worth the trouble.

As to the Lucida fonts, these aren’t required by the platform specification either, but they’re an important part of Sun’s implementation, so I doubt they’ll be removed any time soon.

Posted by Mark Reinhold on September 04, 2006 at 03:23 PM PDT #

Post a Comment:
Comments are closed for this entry.
About

This blog has moved to http://mreinhold.org/blog. <script>var p = window.location.pathname.split('/'); var n = p[p.length - 1].replace(/_/g,'-'); if (n != "301") window.location = "http://mreinhold.org/blog/" + n;</script>

Search

Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today
News

No bookmarks in folder

Blogroll

No bookmarks in folder

Feeds
RSS Atom