This is entirely unsurprising:
# apt-get install japitools
Reading package lists... Done
Building dependency tree... Done
E: Couldn't find package japitools
However, in a couple of days (I don't know how long it takes things to
go through Debian's NEW queue), thanks to Wolfgang, the output will be
different, and that's surprising. Well, it's surprising to me anyway. I
certainly never expected to be an upstream Debian maintainer :)
Also surprising was reading last week's LWN (ok, I outed myself as a
non-subscriber... sorry guys) and encountering a paragraph that started
"Stuart Ballard maintains..." Wow. I feel like a celebrity ;)
At first glance, the percentage rate of improvement in Japi scores
seems to have slowed down (95% hasn't been reached yet) but green is
popping up all over the place. I suspect that it's much harder to make
a significant difference to percentages without adding classes in
Swing, because of the massive numbers of methods they inherit from
Component and JComponent. Regardless, javax.sound.midi went from pure
red to pure green thanks to Anthony (this was a while back but I think
I forgot to mention it), Andrius continued to prove he is a CORBA god
by bringing javax.rmi.CORBA to Japi perfection, Thomas is well on the
way to doing the same thing to javax.imageio, and a whole bunch of
swing hackers continue to improve the greenness there too. The swing
percentage isn't going up as fast as it had been, but watching the
patches list it's easy to see that the Swing team are putting their
effort into making sure it actually works well, as well as having the API covered.
As far as errors against 1.3 go, the javax.naming issue turned out to
be an API bug that japitools can now work around, the java.awt.image
issue was fixed by Thomas and Tom although it actually seems that in
this particular situation the difference was an implementation detail
and japitools has been refined accordingly. I actually submitted a
patch myself (woot!) to fix java.rmi.server and just today Roman fixed
two of the three java.beans errors (this will be picked up by tonight's
run).
To summarize: One remaining error in 1.3 support outside of sound.sampled and swing!
I also submitted a patch to javax.swing.undo to put in "correct" values
of the RCSID fields. These are clearly stupid fields - despite being
constant, their value changes from release to release and vendor to
vendor. And they clearly have no place in a public API. But matching
their values costs us nothing and eliminates some japi errors which
draw focus away from "real" bugs.
Unfortunately Mark disagreed with the idea of following this particular
JDK stupidity and the patch didn't get applied. I originally planned to
workaround this in japitools and add some way to hide these errors but
I don't think I'm actually going to do this. To me the slope of "we
think the spec is stupid so we're not going to implement it" is a
slippery one and I'm uncomfortable with the precedent of hiding an
error just because we've made a deliberate decision to be incompatible
in a particular way. It doesn't matter that we're right that the spec is stupid, we're still incompatible with it and japitools should report that accordingly.
I am adding a "lint" mode to japize though which will enable us to
produce a report of "stupid things in the JDK API". Mainly because it's
very, very easy to implement.
I've become a little distracted from working on it the last few days
though because of Ambivalence. Watch this space for the outcome of that.
