... indistinguishable from magic
effing the ineffable since 1977


Recent Posts


Don't use CVS Japize...

CVS japicompat appears to be working just fine, but last night's results were generated using CVS Japize as well. CVS Japize is not in a state to be used. It doesn't even work in the presence of generics and based on last night's results appears to have serious SerialVersionUID issues too. Oh, and you'll get more false positives because the JDK japis weren't produced by this version.

If you're producing japi files, stick to the released version. When Japize is ready, I'll absolutely let you know :)

UPDATE: Thanks Andrew, the results are good again now that they've been regenerated with the released version.


Heads up: minor japicompat change

I've switched my nightly comparison script to use the CVS version of japicompat starting tonight. This makes very little difference for practical purposes until the new version of Japize is used as well, and that doesn't even work right now because my changes haven't caught up with the generic-support work Jeroen's been doing. However, a bunch of preparatory work was done in japicompat which may have introduced new bugs.

So why did I make the change? Partly because I'd like to know if there were any regressions, and more eyes would be good for that. And partly because it does fix one bug (the single error that was being shown against 1.0 was a false positive, and should now go away) and make it possible to fix another (against 1.1 it shouldn't be an error for Window.hide() to be deprecated because it was undeprecated afterwards, even though it was re-deprecated in 1.5). Low-hanging fruit and all that.

I still have the old version of course - if anyone spots any problems I'll revert immediately.

BTW, 92.64% already! It's not quite 2% per week as I jokingly predicted but it's still frikkin' incredible...

UPDATE: A little birdie tells me that 93.04% might be a number worth mentioning here, which is even more incredible :)


C# 3.0

C# 3.0 looks like it will be really really cool. That is all.

(Although I'm sure I'll have much more to add once I go over the specs in more detail and think about them a bit...)


Two percent per week?

As I already mentioned, Tom blogged on Monday about the compiler change that put Classpath's japi results against JDK1.4 at over 90% - specifically 90.47%. I remember that because it was a bigger improvement than I could account for based on the compiler difference I knew about. I attributed the discrepancy to compiler differences I didn't know about, but now I suspect it may have represented real improvement.

You see, it's now four days later, and the same page is now showing 91.49%. That's over a full percentage point difference and only 8.5% to go!

At that rate of improvement the numbers will hit 100% in a month ;)

The results against JDK1.3 have now climbed over 90% for the first time too. At first glance it's weird that the 1.3 percentage should be lower, but it actually makes sense - the APIs that were new in 1.4 are mostly covered extremely well already; the biggest hole is in areas that were also in 1.3 (mostly Swing, since that's such a disproportionate chunk of the size of the JDK API), and since 1.3 is smaller that hole represents a higher percentage.

Classpath hackers, your progress is insane! Congratulations!

In other news, after a long hiatus, I'm actually making progress towards getting some support of JDK1.5 features into japitools. We'll see if my motivation holds up long enough for the results to actually be visible. There are many evil (<mikemyers>EEE-VILLE</mikemyers>) corner cases to be handled in the generics world...


Undeserved credit

Tom, I'd love to take credit but actually it's Andrew John Hughes who produces the japi files used in those comparisons; he's the one who pushed Classpath over 90% :) (mutter mutter people who don't enable comments on their blogs so the only way to reply is by another blog posting mutter mutter)

Previous Page