Skip to main content

Carbonizing Java

Posted by daniel on June 17, 2004 at 5:48 AM PDT

How can we remove classes and methods from J2SE with minimal breakage?

When we recently ran a poll about which packages should be added to the core J2SE distribution, we received a lot of email and feedback that said "nothing should be added but much should be removed". How do we do this without breaking running apps? We don't want to hear that the new version of Java is broken just because someone's favorite legacy app no longer works.

As often is the case, we in the Java community can benefit from the lessons learned by developers in other settings. The latest Joel on Software considers this issue of bloat vs. maintenance in the Windows world. In Also in Java Today we feature Joel Spolsky's essay How Microsoft Lost the API War. He contrasts what he sees as "two opposing forces inside Microsoft, which I will refer to, somewhat tongue-in-cheek, as The Raymond Chen Camp and The MSDN Magazine Camp. ... The Raymond Chen camp is all about consolidation. Please, don't make things any worse, let's just keep making what we already have still work. The MSDN Magazine Camp needs to keep churning out new gigantic pieces of technology that nobody can keep up with." Spolsky reports that the MSDN camp has won and the result is "Outside developers, who were never particularly happy with the complexity of Windows development, have defected from the Microsoft platform en-masse and are now developing for the web."

Check out this extreme story from the Raymond Chen school at Microsoft from Joel's essay:

I first heard about this from one of the developers of the hit game SimCity, who told me that there was a critical bug in his application: it used memory right after freeing it, a major no-no that happened to work OK on DOS but would not work under Windows where memory that is freed is likely to be snatched up by another running application right away. The testers on the Windows team were going through various popular applications, testing them to make sure they worked OK, but SimCity kept crashing. They reported this to the Windows developers, who disassembled SimCity, stepped through it in a debugger, found the bug, and added special code that checked if SimCity was running, and if it did, ran the memory allocator in a special mode in which you could still use memory after freeing it.

Spolsky points out that "A lot of developers and engineers don't agree with this way of working. If the application did something bad, or relied on some undocumented behavior, they think, it should just break when the OS gets upgraded. The developers of the Macintosh OS at Apple have always been in this camp. It's why so few applications from the early days of the Macintosh still work."

But one of the things that Apple did with Mac OS X was find a path that developers could use to bring their existing applications to the new OS. Apple had to find this path because they had burned developers with plans for operating systems that had never shipped. The idea was Carbon. Here is a subset of the existing APIs that we will support going forward. You can test your code to see what parts of it need to be rewritten. Your transformed code won't be able to take advantage of all of the new features of the new OS, but it will run on classic and on the new platform.

Isn't it time to do this for Java? There are many redundant ways to accomplish the same task. There are many APIs with too many exposed methods. There are classes and methods that have been deprecated for five years. Carbonize them.

Take a breath in all of the functionality that we add to each release and take a long hard look at what needs to go. Make 1.6 the Deprecation - we mean it this time release. Then don't put out any more 1. releases. It is too confusing to move to 2.x releases as we already call this Java 2. Draw the line in the sand and announce that the next release after 1.6 will be Java 3.0. Work for the next few years on performance and reliability so that we can remove all of those warnings that Java shouldn't be used in a critical situation.

We launched a new discussion on Stripping down J2SE. Join us in our discussion of what should be stripped out of the core and how non-core pieces shold be made available to applications that may require them to run.


Jim Cushing welcomes you to this latest discussion
in today's Forums in his thread
Does Java need to go on a diet?
Jimothy notes "In the days of Java 1.1, a user could download the complete JRE in under 3 MB. Today, with J2SE 1.4, the JRE is nearly a 15 MB download, and the JDK is nearly 50 MB ...Are there deprecated classes and methods that could be removed altogether? Should entire packages be removed from the J2SE distribution and made available as separate downloads? ...Let's explore the consequences of the growth of J2SE, and what could be done to address these issues. What can and should be done to benefit users, developers, and the Java platform itself? "

Chris provides Another good reason to use a BSD license for book code saying "Practically the only things the BSD License concerns itself with are replicating the copyright statement and indemnifying authors from defects in the software. The MIT License is similar. And that indemnification might be a good thing to have on there, as pointed out by Bill Dudney's weblog, in which a bug in some Java Almanac code is found to be causing problems in multiple systems into which it has been pasted verbatim."


Gosling invites you to Ride the release train
in today's
Weblogs. He becomes the latest in a series of bloggers to ask that you download the weekly builds of J2SE, "Try it out and let us know how you like it. If it works well, we'd like to continue in subsequent release cycles."

Speaking of releases, James Todd announces JXTA 2.3 has shipped and that the performance is much improved.


There is also JXTA news in today's Projects and Communities. Download version 1.2 of JXCube, a "fully distributed collaborative application that enables users to collaborate using various functions such as chat, messenger, file sharing or schedule management."

Project owners at java.net can collect access information as an Apache log file using the Logger project. Find out who is referencing your project, how many people are downloading your software, and which pages are accessed the most.


In today's java.net News Headlines
:

Registered users can submit news items for the href="http://today.java.net/today/news/">java.net News Page using
our news submission
form
. All submissions go through an editorial review by news director
Steve Mallet before being posted to the site. You can also subscribe to
thejava.net
News RSS feed
.


Current and upcoming
Java Events
:

Registered users can submit event listings for the href="http://www.java.net/events">java.net Events Page using our href="http://today.java.net/cs/user/create/e"> events submission
form. All submissions go through an editorial review before being
posted to the site.


Archives and Subscriptions: This blog is delivered weekdays as the
Java
Today RSS feed
. All java.net members can subscribe to the email
updates for the site at the href="https://java-net.dev.java.net/servlets/ProjectMailingListList">
java-net Mailing Lists page. You must be logged in to subscribe
to
the javanet_Daily and javanet_Weekly lists. Also, once this page
is no longer featured as the front page of
java.net
it will be archived along with other past issues in the href="http://today.java.net/today/archive/">java.net Archive.