Skip to main content

Sacrificial Bonfire

Posted by editor on August 30, 2006 at 7:31 AM PDT

Is stuff really going to be taken out of the JDK?

Nearly every proposal to add to the JDK gets poke-checked with a reply of "bloat" from some corner, which is probably appropriate to some degree. Everybody's copy of the JDK has bytes they don't use, which means more deadweight to download. It's just that each of us uses a different set of features, so your "bloat" might be my bread and butter.

But I think we're seeing the first instance of a serious intention to take something out of the JDK for everybody. Mark Reinhold talks up the proposal to do this in Removing features from the Java SE platform, in which he says "Perhaps the most significant recent change to the JSR 270 specification is the definition -- and first application -- of a policy for removing existing features." He goes on to discuss that while Java's history of only adding features has led to binary compatibility by not pulling the rug out from under an application when the JDK updates, it's a problem because "both the conceptual complexity of the platform and the size of minimal Java Runtime Environment (JRE) download bundles have, in turn, also grown monotonically."

The proposed removal process is targeted to large subsystems -- think packages, not classes -- and would turn no-longer-required features into optional components, meaning that a Java platform implementation could pass the TCK without containing the removed feature.

So who's toast first? Probably javax.sound.midi, which totes along a half-megabyte data file, and is thus a significant contributor to the size of JRE downloads while actually being used very infrequently in practice. Mark identifies CORBA support as another prime candidate for removal, but while unpopular, it appears to be fairly tightly coupled to the popular RMI-IIOP.

Mark closes by noting the Java Module System (JSR 277) proposal, which might make removals of stuff like CORBA easier, as it would allow removed packages to be downloaded, installed, and versioned fairly easily.

So what do you think? Personally, I'm the last one who'd cheer Java Media taking another step backwards, though javax.sound.midi is admittedly a little-used white elephant, one with a pretty pathetic history -- despite having a API design that carefully managed the use of software synthesizers and external devices, it was years before the latter actually worked, and then only on Windows.

Maybe it is time to cut the fat from the Java platform, the API's that have either become obsolete or never worked out anyways. Or maybe that will lead to a compatibility nightmare of "yeah, you've got Java, but not all of it". What do you think? Is this the right idea, and the right approach? Maybe feature removal would be a good topic for discussion on the JDK forum.

Also in Java Today,
a new version of the Sun Grid computeserver project has been released and is available for download. With this release, developers can use standard Java logging APIs in their code, configure Java logging levels for both on-grid and debug execution from within NetBeans, and examine log output using a new log viewer, also within NetBeans. The UI has been improved through numerous enhancements, including the re-organization of some property sheets. A new Tree Search design pattern has been added to the documentation, and descriptive use-case examples have been added for most design patterns.

With its new, annotations-based framework, JUnit 4 has embraced some of the best features of TestNG, but does that mean it's rendered TestNG obsolete? In JUnit 4 vs. TestNG, Andrew Glover considers what's unique about each framework and reveals three high-level testing features you'll still find only in TestNG.

dimwight reconsiders the idea of Closures and Swing
in today's Forums:
"In a sense Patrick you are right, but I guess anyone visiting this forum will have a strong interest in the broader Swing issue of code clutter due to event listeners. Adding more syntactic sugar to Java in the form of closures is not going to resolve the deeper problem - that so much event handling code seems required to define useful functionality for a GUI."

Looking ahead at GlassFish development,
jr158900 seeks
Feedback on proposed JDBC 4.0 support for GlassFish V2:
"Please provide us comments/feedback on the proposed JDBC 4.0 support in JDBC-Resource Adapter for Glassfish V2. The document describing these features can be found at: JDBC-4.0-RA-OnePager.txt. Feedback/review period closes 2 weeks from today. Any comments received after that would not be considered for this release (GlassFish V2)"