sab39

... indistinguishable from magic
effing the ineffable since 1977

Categories

Recent Posts

Archives

Oh Japi Day

10/7/2005
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.

 
Previous Page
RSS