At the same time as I had a great big blog dummy spit about a known memory leak in java.util.concurrent
, I did the constructive thing and submitted a bug report. My basic point was that, if the code can’t be fixed, the problem and its workaround should at least be noted in the Javadoc.
Several weeks later, the bug report has wound its way through the system and appeared on Sun’s bug database. Sun’s initial evaluation says:
Unfortunately, we don’t modify the javadoc for update releases. This bug is fixed in JDK 6.
Nice to know the code is fixed in the future. Unfortunate indeed that programmers don’t program in the future. (I should expand upon this line of thought for another few sentences, but I can’t think of anything to say that doesn’t involve bad words or outrageous condescension. So let’s skip ahead to a new paragraph, and rosier thoughts.)
Perhaps open sourcing Java will help. Perhaps, as control of Java moves more into the hands of the open source community, the JDK engineers will start to have a bit more respect for developers trying to build working software on top of their libraries. They certainly could learn from the way other open source languages treat programmers.
Comments
I think I can beat that. Try http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4639407. This bug, which makes Calendar behave differently in different years or time zones, wasn't fixed in JDK1.4 because "this fix breaks a JCK test". Huh?!! Why not fix the broken test too...
The JCK is the test to verify that an implementation implements the java spec correctly...if it's in the test, it means that it's part of Java itself, even if it is wrong. So they can't just fix it without breaking software that depends on it (and suddenly making all other VM implementations fail certification), which is probably why it has to wait until a major release where backwards compatibility restrictions are relaxed.
Stephen: Yep. You win.
Rob: This is rather the point. Sun's big licensees are paying for Java development, not developers, and the interests of licensees and developers are not always aligned.