About the Author
Andy Tripp is a Java consultant and entepreneur. He has over 20 years of software development experience. and has been using Java since it was a beta. He is President of his own company: Jazillian, Inc, which makes C-to-Java translation software. He hold bachelor's and master's degrees in Computer Science.
Discuss this article with Andy
Spotlight Features

The Rich Engineering Heritage Behind Dependency Injection

Andrew McVeigh takes us on a tour of the rich heritage behind dependency injection, what it represents, and tells us why its here to stay.

NetBeans 6: Matisse Updates

NetBeans 6 delivers great updates to the Matisse GUI builder. Spend a few minutes with Roman Strobl and get an expert briefing on what's new and what has changed.

Introduction to Groovy Part 3

In this, the third and final installation of Andres' Introduction to Groovy series, you learn about how Groovy handles variable numbers of arguments, named parameters, currying, and more about Groovy operators. Including, some new operators.

Easier Custom Components with Swing Fuse

Swing Fuse (actually just Fuse), is a framework designed to make it easier to create your own custom desktop components. In this article, Daniel Spiewak shows you how to get started and provides sample source code you can download.

Benchmark Analysis: Guice vs Spring

Willam Louth shows how he uses JXInsight Probes to investigate probable performance issues with code bases that he is not familiar with. He also highlights possible pitfalls in creating a benchmark, as well as in the analysis of results.

I Fixed the JDK!

Sun recently announced a new "JDK Collaboration" project on java.net. The idea is to have an easy mechanism by which people can submit fixes to the JDK and actually have those fixes incorporated.

I decided to test out this new mechanism by submitting a few bug fixes. Before I get into the details of my experience, here's a little background...

Java and "Open Source": Good News and Bad News

Regarding Java and Open Source, I have some good news and some bad news...

  • The good news is that Java is "open" in the sense that you can look at its source code
  • The bad news is that it's not truly "open source" according to the official definition.
  • The good news is that you can see the source so you can work around problems.
  • The bad news is that you can't actually fix the problems in the JDK.
  • The good news is that you can fix the problems in your own version of the JDK.
  • The bad news is is that you can't distribute your own version to your customers.
  • The good news is that you could always email your fix to Sun and hope that they incorporate it.
  • The bad news is that that's never really worked at all.
  • The good news is that Sun has now set up a real mechanism to submit bug fixes,
  • The bad news? Well, we'll have to wait and see if there is any bad news.

Signing Agreements

Before submitting a fix, I had to do some legal paperwork: I signed the Sun Contributor Agreement and faxed it to Sun (note to Sun: include the fax number (650)-482-6557 on the form please!). This agreement tells Sun that it's ok (on a legal basis, not a technical basis!) for them to accept my fixes. It basically assigns joint ownership of the fix to both me and Sun.

Whenever you download the JDK, you need to sign a license. When downloading it with the intent to make fixes, you'll need to choose the Java Research License (JRL) which has its own FAQ. And, you apparently need to apply for "jdk.researcher" status in the "JDK Collection of Projects" at java.net. This is all explained on Sun's How to Collaborate page.

Downloading the JDK

I went here and downloaded and installed the JDK 1.6 ("Mustang") source from this page. This is a little confusing, because you actually need some "JDK Binaries for Source Build 6.0". These are just a few platform-specific binary files that you need to be sure are installed in order for you to successfully compile the JDK. [Note: If you're new to dealing with Sun: "1.6" and "6.0" are interchangeable... Sun seems to enjoy giving everything two different version numbers to confuse us].

Next, I downloaded and installed the normal binary JDK 1.6 distribution from here. I happened to download the Windows version, and I agreed to the JRL.

Compiling the JDK Source

Once I'd downloaded the source, there was a README.html file in my top-level source directory that contained instructions for compiling on my platform. Unfortunately, the Windows version requires that I have MSVC++ 6.0 with Service Pack 3 (not 4!) installed. Well, I certainly don't have that! Oh well, I guess I'll have to get a copy. But in the meantime...

I found a forum post that provides an ant build.xml file to just compile Swing, not the whole JDK. And not only that, running it will recompile all of the core Java classes too.

Submitting a Fix

Once I'd signed and faxed the Sun Contributors Agreement, actually submitting my fixes was very easy. I used Sun's Submit a Fix page. To access this page, you need to create a java.net account if you don't already have one. Also, they ask you to supply a "GNU unified diff" specification of the changes that you made. The diff command is one of many of UNIX/Linux commands. If you're on Windows, you could download Cygwin to get all these commands.

Fix 1: Compiler Warnings

Next came the fun part: picking a bug to fix. I had noticed a bunch of javac compiler warnings when compiling the JDK. Fixing these seemed like a reasonable first fix. There were about 10 warning messages like this: 

warning: non-varargs call of varargs method with inexact argument type for last parameter;

These were clearly caused by someone changing some methods to use "varargs" without changing all the corresponding method calls. What needs to be changed was clear and simple. So I made the changes and recompiled. However, the "Submit a Fix" page asks you for a test case, and I surely have no idea how to test this fix, as I've just changed 10 random method calls throughout the JDK. So I explained the situation as best I could by saying: "fixed various code to remove varargs-related compiler warnings" when I submitted the fix. I also included the "diffs", as requested.

Oh, and yes, this is bug #6207243 in Sun's Bug Database. And the bug even says "Now that the Mustang snapshots are being released to the community, we need to be more vigilant about keeping our builds warning-and-error-free, and this is one small part of that effort". Ahhh, the pleasures of almost-open-source!

The interesting thing about this first fix will be to see how quickly they can get the fix in, and how much (if any) testing they will do for this. Having spent many years doing software development at large companies, I seriously doubt that they'll do any specific testing for this, and none can reasonably be expected. These sorts of problems happen every day. You fix them and move on.

Fix 2: Windows Folder Icons

Continuing my quest for easy-to-fix bugs, I scanned the bug database and I came across this bug which says that the JTree folder icon doesn't match the icon in Windows XP. That seemed easy enough to fix, and it was (or so it seemed - see the "Hearing Back from Sun" section below). It should just a matter of finding the appropriate Windows XP icon.

So I used google to find the right icon, replaced the icon in directory where I had downloaded JDK1.6, and tested it. Turns out there are two icons: "open" and a "closed" versions.

When submitting Sun only wants you to specify a "diff". They have no mechanism for uploading non-text files, such as these images. So I made the icons available for download from my website, and explained that in my submission. I also provided a unit test case as a main() program in the submission.

Some things to watch for here are:

  • They request unit test cases in "JUnit format", but I just gave them a simple "main" program. Do they really care?
  • Will Sun provide a way to upload binary files? That would make a lot of sense, and it's easy enough to do.
  • I almost missed the fact that there were two versions of the icon. I wonder what would have happened if I had only submitted one. Would Sun's testing have caught it? Would they be mad at me once they found out, and would they still trust me after that? I suppose I'll never know.

Fix 3: Properties.load() needs a Reader

I had originally found out about this whole "fix the JDK" effort by Sun by reading this post at Javalobby. In a reply to that post, I asked for bugs that people might want fixed, and someone mentioned Bug 4094866. This bug says that, darn it, you've deprecated StringBufferInputStream, and yet the Properties.load() method still takes an InputStream (not a Reader), and so now I can't load my properties from a String without getting an annoying compiler warning. The bug asks specifically to have an additional Properties.load() method that takes a Reader argument, but also asks for a more general way to convert from a Reader to an InputStream.

I added a Properties.load(Reader r) method, tested, and submitted the fix to Sun. In the submission, I explained what I did, and clearly point out that I fixed the specific problem (letting you read Properties from a Reader), but not the general problem (providing a general Reader-to-Input-Stream class). A quick google search for ReaderInputStream shows that many people have already implemented the general solution, but these implementations are under various licenses like LGPL, so I wasn't going to just take one and submit it.

So this one will be interesting to watch. Will Sun just take the specific fix I sent and close the bug making some people happy but making others angry that the bug was closed without a more general fix? Or will they spend some time and either reuse someone else's solution (making sure there are no license issues), or implement their own?

Normally, I'd guess that they would just implement their own. I would only take someone an hour or two, including testing. However, this bug has been open since 1997! If they haven't fixed it in the last 8 years, why now?

Hearing Back from Sun

I submitted my first bug fix on a Friday night, March 18, 2005. I got the following email back the following Tuesday, March 22, 2005: 


-----------------------------------------------------
Hi Andy,
               Thank you very much for your submission. I will be working with you on
getting your bug fix through the JDK development process and integrated into
JDK source. This fix looks fairly safe and should go through without any difficulty.

Here are my next steps :
1) Generate a workspace and build with your changes.
2) Produce a review page (webrev) based on this workspace.
3) Review it with the respective file/module owners.
4) Commit changes back to pre-integration workspace.

Once this change is commited back to pre-integration workspace, it
will take about 2 weeks for it to get into a release build. So you can
expect this process to take atleast three weeks.

I will keep you updated and will contact you if any information is needed.

Thanks again for your contribution. Your contribution will help to improve
Mustang. Thanks,

Regards,
[Name Deleted], on behalf of JDK team.
-----------------------------------------------------
Three weeks later, I got this email: 


-----------------------------------------------------
Hi Andy,
             You fix for the bug 6207243 has been commited to Mustang,
with some changes (to avoid double-wrapping of arguments in case
of RegistryImpl). I wanted to let you know that your contribution does
not completely fix all the cases that 6207243 addresses. So I will file a
new bug to keep track of remaining warnings.

I also wanted to let you know that since your contribution has been
integrated, you are due for a T-Shirt . Can you let me know what
size you would prefer ? Thanks,

Regards,
[Name Deleted]
-----------------------------------------------------

On Fix 2, the one with the Windows Folder icons, I got this email on March 23rd: 


-----------------------------------------------------
Hi Andy,
        Thank you for your submission. While I would like to take the fix you
suggested in the form of the images, it does not fix the problem correctly. It
turns out that we need to get the image directly from Windows itself,
This is because the image will change based on the theme you are
using under windows. Also, there may be legal issues with simply capturing the
image and reusing it. Having said that, it turns out that [Name Deleted],
an engineer in the Swing team has got a fix for this that extracts the image out
of the appropriate place in Windows. He is currently working on fine-tuning
the code. As far as putting the static image in the directory you suggested,
that is just a fallback in case we cannot find the right image from Windows.
If you are interested in the actual, fix I can send you a pointer to the
fix once it is integrated.

Your involvement in mustang is very valuable and we encourage
you to contribute any new fixes you may have. Thanks,

Regards,
[Name Deleted]
-----------------------------------------------------

So this is an enlightening result: my fix does work, but Sun was already working on the more general fix - to use Windows APIs to get an appropriate icon, which would be affected by the user's current choice of theme (i.e. "skin"/"look-and-feel").

It's been about a month now and I still haven't heard back about the third fix I submitted - the one about the Reader and Properties class. I do know that they got the submission, because I got a form letter back when I first submitted it: 


-----------------------------------------------------
Your suggested bug-fix has been assigned an internal review ID of: 420106


This ID is NOT visible on the "Java Developer Connection" (JDC).

We currently have a one week response time for responding to
submitted fixes.

We will review your report. Depending upon the completeness of the
fix, we may need to contact you for further information. You will be
notified by email in either case.

We will try to process all suggested fixes in a timely manner, but we
make no promises about the amount of time in which a bug will be
fixed. If you just reported a bug that could have a major impact on
your project, consider using one of the technical support offerings
available at the Support, Education & Consulting Home Page or use the
Sun Support Access programs on the Sun Developer Connection.

Thank you,
Sun Microsystems, Inc.
-----------------------------------------------------

Conclusion

Overall, the new Sun "JDK Collaboration" project seems to be working pretty well, at least for simple fixes. I submitted three fairly trivial bug fixes to JDK1.6 (aka "Mustang"). One was accepted and took about three weeks to be incorporated into the official branch. A second fix was not general enough, and Sun is still working on a more general fix. Sun should update the evaluation of the bug in the bug database to indicate the true problem and that they're working on a fix. And the third fix was submitted a month ago, and I'm still waiting to see what happens with it.

The submission process was straightforward. I just signed up for a java.net account, added myself to a project, and submitted changes using an easy to use web page. One minor enhancement Sun could make would be to allow uploading of binary files, such as icons. The fact that Sun asks for a "JUnit-style test case", and a "GNU unified diff" may throw some people off, but they seem like reasonable requests.

In all three cases, Sun did a good job of communicating: I got an automatically generated form letter immediately after submission of the fix, and a followup email from a real person once they had analyzed the fix. And once a fix had been incorporated, I got a third email telling me so (and letting me know I get a free T-shirt).

And, of course, the good news is that my submitted fixes seemed to find their way to the right person within Sun. That may not sound like a big deal, but it's probably quite an accomplishment for a fairly large company like Sun.

Though I haven't heard back on one of my three fixes, overall I'd give Sun a "B+", or "3 stars out of 4", or "very good" rating.

And so the final good news is that I actually "fixed the JDK" and I'll get a T-shirt for my efforts.
The bad news is that I had to ask for an extra large.