Don't use CVS Japize...9/20/2005
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 change9/19/2005
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.09/13/2005
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?9/9/2005
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 credit9/5/2005
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)
|
