(Thanks to Steven for today's pun)
For a long time it seemed that my work, and Jeroen's, on the 1.5 support
in Japitools was taking forever and nothing was actually being
achieved. We had file formats specced out, sure, and later on we had
data structures built to represent 1.5 features, and that kind of
thing. But it was all under the hood, and most of the time Japize
wouldn't even run, and even if it did japicompat couldn't make heads or
tails of its output. This state went on for weeks - months, actually,
the file format spec was originally written a long time ago, although
for most of that time no work was being done.
So it's quite surprising and very rewarding that within a week of the
first successful japicompat results being produced we suddenly appear
to have almost feature-complete 1.5 capability. Annotations are missing
- they'll be worked on next - and there are a few loose ends to tie up.
I also want to compare the results line-by-line to the released version
on all pre-1.5 versions and make sure every difference is accounted for
before I start suggesting that people primarily use this version. But
wow.
It's nice to have progress of my own to report instead of just watching
in awe as the Classpath hackers churn through the percentages, but
they've certainly not been standing still. It was September 5th that I
first was amazed to see Classpath creep past the 90% mark against 1.4 for
the first time; now it looks like 95% will most likely be achieved
sometime this weekend. You guys have halved the gap in less than a
month!
The remaining 1.2 bugs are rapidly biting the dust too. Roman
implemented ActivationGroup_Stub and - YES! - the loadClass method that
was the last remaining 1.1 error. Tom fixed the two BeanContextServices
svuids and nipped an incorrect ActivationGroup_Stub svuid in the bud.
Thomas sorted out the incorrectly-abstract method in java.awt.print.
The upshot of all this is that there are now only 6 errors outside of
swing against 1.2. You might think there are only 5, but I'm afraid the
CVS Japi knows how to look for fields declared in the wrong place and
it found another one in java.awt.image. Oh, and only a single missing
field in javax.naming on top of these would limit 1.3 errors to only javax.rmi.CORBA,
javax.sound.sampled, and swing...