... indistinguishable from magic
effing the ineffable since 1977


Show All

Recent Posts


The reinvigoration of Classpath?

(Disclaimer: I'm just observing all this from the sidelines; my opinion is almost entirely derived from Planet Classpath and the Classpath mailing lists. If I'm wrong on some salient point, please comment and let me know!)

I'm very pleased to see that the Classpath project seems to be picking up some of the steam it lost on the announcement of OpenJDK. I have mixed feelings about OpenJDK itself: on the one hand, Sun did exactly the right thing by releasing the JDK under the best possible choice of license as we'd all wanted for years; on the other hand, I've seen at least two blog entries on Planet Classpath in the past week that were variations on "hooray, the trivial patch I submitted to OpenJDK the week it was released has been accepted a mere three months later!"

IcedTea appears to have picked up some of this slack and last I heard had built a mostly-working Java implementation by plugging in Classpath code to fill the holes in OpenJDK. Haven't heard much about it lately though - has development stalled or are people just not blogging about it?

However, part of me feels that IcedTea is approaching the problem from the wrong end. The code that the Classpath developers have labored over for ten years deserves a higher place than being used as filler to patch the holes in an inferior, ex-proprietary codebase. I'm not trying to argue that Sun's code is "bad" or that Classpath's code is perfect, but I do know that code developed in the bright light of public view, with no schedule pressures other than "when it's right", is invariably [UPDATED: Jeroen points out in the comments that this isn't so invariable after all] higher quality than code developed inside a large, bureaucratic organization with constant pressure to ship to a deadline. The fact that these things have historically affected Java's development is apparent in the public API: public members whose types are nonpublic, public RCSID fields, serialVersionUID fields defined on interfaces.

The difference is apparent in the sheer size of the codebases - the JDK is several times the size of Classpath, despite Classpath providing the vast majority of the same level of functionality. (I'm actually considering sticking with an older version of IKVM for this reason - file size matters when you're building an installer that's being shipped over the network). It's apparent in the fact that Classpath has a clean API for targeting multiple VMs including VMs for which native code is unnecessary, where the JDK's VM interface is internal and relies heavily on native code.

It seems to me that there would be a lot of value in approaching an OpenJDK / Classpath merge in the same way the libgcj and Kaffe merges were approached: compare the code on a class-by-class basis, bring in whichever implementation is best, and change it if necessary to account for things the other implementation did better. My gut instinct says a lot more Classpath code would survive that process than is surviving today in IcedTea - and the end result would be significantly smaller, cleaner, faster and bug-free-er.

I don't know whether the copyright ownership issues have been resolved yet to make it possible to actually pull OpenJDK code directly into Classpath though.

Regardless of what approach ends up being taken, though, it's good to see work happening on Classpath again, and a new release being contemplated. I guess it means I need to get those darn Japi runs happening again though!


Confused but Japi

The Japi runs for the last couple of days have gotten very confused. Yesterday they started believing that JDK7 had no classes in it; now they seem to believe that Classpath doesn't.

I'm not sure what's going on just yet, and I haven't yet had time to do any actual investigation. In the meantime, I killed today's run as soon as I noticed what was going on; no Harmony results today because I'm almost sure they'd have been bogus anyway.

I'll keep you posted.


Japi New Year!

Thanks Casey for tackling the 7 issues. 1/1/10+2!


Japi Holidays to all!

Nearly a month since I blogged about Japi progress. I must be slipping.

Since then with respect to 1.4:
  • As Andrew mentioned in that chat log, he fixed the remaining beancontext issues on December 1st. As far as I know he's still looking for anyone, anywhere, who actually has any code that uses those methods.
  • Roman implemented two in datatransfer and one in print on December 11th.
  • And two in on December 12th.
  • On Christmas Eve Andrew eliminated the last two errors.
This brings us down to 1/1/17+2 missing methods versus 1.2, 1.3, 1.4. That's almost cut the 1.4 errors in half again this month! They break down as follows:
  • The 1.2/1.3 error is in java.text. Mario is working on this one, I believe. As I understand it, it exposed some deeper Unicode-related issues that need to be addressed first - and will presumably result in improvements elsewhere too.
  • Seven in Not a clue.
  • Six more in
  • Two methods, two constructors (and three serialversionuid minor issues) in
  • One more to go (drag'n'drop related) in Swing.
  • And since I'm mentioning minor issues, even though I'm not including them in the count: a few more serialversionuid issues in external code that we inherit from the upstream distributors, specifically dom and sax. I believe these have been reported to the upstream suppliers of the code with no results, which is disappointing. Perhaps these won't be fixed until OpenJDK code can be pulled in...
Why am I still so fixated on the 1.2/1.3/1.4 results even though the current version is now JDK6? Because I like the idea of being able to say something is finished. For a long time - embarrassingly long, in fact, especially if you tried to advocate Classpath to a Java developer - we were "nearly 1.1". It doesn't matter if you also say "and a whole lot of 1.2, 1.3 and 1.4, and some of 1.5", the fact that we couldn't claim that even 1.1 was finished was what (a certain subset of) people heard. Now we're "nearly 1.2, nearly 1.3, nearly 1.4". Coverage of 1.5 and 6 are making good progress, but those things would sound a lot better if the sentence started with "1.4 is finished".

There are certainly also things from 1.4 that lie outside of API coverage that aren't finished. I'm not sure whether there's any definitive list of those things; it's a lot harder to know what they are when you can't write an easy tool like japitools to list them. I think those things are important too - I'm just not in a position to blog what they are. One I encountered in my own development was jks keystore format support.

None of that, though, detracts from the fact that excellent work is being done on 1.5 and 6 support as well, by Andrew and others. The percentage changes don't seem terribly impressive (at the beginning of the month Classpath's generics branch was at 95.5% good, 4.4% missing versus 1.5, and 88.72% good, 11.03% missing versus 6. Now Classpath IS the generics branch and those numbers are 95.56% good, 4.31% missing versus 1.5 and 88.93% good, 10.87% missing versus 6). However, the Java platform these days is HUGE. An improvement of 0.21% reflects quite a lot of work, especially considering that it was all methods in existing classes, and the way Japi weights things, those don't count for much compared to a whole new class, even if the class is small.


Making a Japi face - Classpath hackers are awesome

(03:15:01 PM) mjw: BTW. I am going to create the 0.93 branch now.
(03:15:22 PM) mjw: Unless there is something that really, really, really needs to go in in the next 30 minutes.
(03:15:46 PM) sab39: mjw: well clearly we really really need those last 6 beancontext methods and the one in java.text ;)
(03:16:19 PM) mjw: sab39, That is OK. You still have 28 minutes.
(03:16:40 PM) sab39: mjw: well my way of fixing japi errors is to poke other people until they do it
(03:16:52 PM) sab39: mjw: so... wonder how long till my new blog post hits planet ;)
(03:17:03 PM) ***mjw adds a note to keep out of reach of sab39
(03:17:14 PM) sab39: mjw: you're not immune, remember RCSID? ;)
(03:17:20 PM) mjw: sab39, It's there now
(03:17:31 PM) ***sab39 must have timed posting it well
(03:17:36 PM) tromey: your blog showed up on mugshot just now
(03:19:13 PM) neugens: sab39. ping
(03:19:23 PM) neugens: hehe, I've read your blog
(03:19:33 PM) sab39: neugens: pong
(03:19:43 PM) neugens: sab39: I'll try to take care of the missing error for the text package
(03:19:52 PM) sab39: neugens: cool :)
(03:20:00 PM) neugens: sab39: not sure it will be in the 0.93 release though :(
(03:20:06 PM) rkennke: sab39: hey it works!
(03:20:16 PM) sab39: rkennke: never fails
(03:20:31 PM) sab39: neugens: what, you can't get it working in 30 mins? ;)
(03:20:40 PM) neugens: 30 minutes?
(03:20:41 PM) neugens: ouch!
(03:20:50 PM) neugens: I need to push a fix for decimal format first!
(03:20:54 PM) ***neugens rush
(03:20:59 PM) ***neugens is away: I'm busy
(03:21:10 PM) rkennke: lol
(03:21:34 PM) sab39: :)
(03:21:34 PM) mjw: O boy.
(03:22:09 PM) mjw: I can pick up fixes on the release branch later also.
(03:24:01 PM) gnu_andrew: sab39, the problem with fixing those beancontext ones is that I've not seen any real testcases
(03:24:15 PM) gnu_andrew: sab39, I can throw something in but won't be 100% as to whether it's right
(03:24:37 PM) gnu_andrew: sab39, e.g. the proxy ones would intuitively suggest that you have a provider which you call
(03:25:35 PM) ***sab39 is giggling like an evil maniac right now. It really does never fail ;)
(03:26:01 PM) rkennke: sab39: haha
(03:26:23 PM) rkennke: gnu_andrew: I'd say throw it in. As long as noone complains ... B-)
(03:26:50 PM) robilad: rkennke: you're talking to the guy who talked me into starting to merge in classpath into kaffe back in 2003. ;)
(03:27:14 PM) sab39: gnu_andrew: I imagine if there are problems with an implementation you're more likely to get decent bug reports if it's an attempted implementation than if it's just entirely missing, too
(03:27:59 PM) sab39: I don't know whether to feel proud or guilty that the net effect of my gently and not-so-gently nudging other people to do stuff is so vastly disproportionately higher than the amount of actual work I've done myself ;)
(03:28:26 PM) tromey: sab39: arguably motivating other people is harder and more useful than doign the actual work :)
(03:28:26 PM) rkennke: robilad: hehe
(03:29:11 PM) gnu_andrew: sab39, good point, I'll hack something together and stick it in
(03:29:17 PM) sab39: robilad: well your starting that also prompted me to un-abandon japi after 2 years of not having touched it... not that that compares with the amount of work you did of course :)
(03:29:24 PM) gnu_andrew: sab39, no-one has even cried about them being missing yet...
(03:29:30 PM) mjw: sab39, The trick is to create your own reality-distortion-field in which you actually believe all the work was really yours anyway.
(03:29:36 PM) sab39: gnu_andrew: I have ;)
(03:30:00 PM) sab39: tromey: thanks, that's a heck of an ego boost ;)
(03:30:59 PM) robilad: sab39: you're good, and we like you ;)
(03:31:10 PM) sab39: mjw: I'm not sure even steve jobs could create *that* big a reality distortion field
(03:31:14 PM) sab39: robilad: aww, thanks
(03:31:19 PM) robilad: we also like casey very much, but he seems to not be around tonight.
(03:31:31 PM) sab39: <robilad promiscuous=true>/me hugs</robilad>
(03:31:46 PM) sab39: (that never gets old ;) )
(03:32:21 PM) gnu_andrew: sab39, I meant in terms of actually using it of course... ;)
(03:32:33 PM) gnu_andrew: seems sab39 is the Classpath cheerleader... :)
(03:32:43 PM) ***robilad hugs sab39 back .. thanks god it's friday! and heads out for a beer
(03:32:51 PM) robilad: later, mates
(03:32:52 PM) ***sab39 waves his pompoms
(03:32:59 PM) sab39: (now there's a disturbing picture)
(03:33:16 PM) sab39: bye robilad
(03:33:36 PM) sab39: (I'm so blogging this conversation btw)
(03:34:21 PM) Stephmw: I'm sooooo happy I didn't make any sarky comments then
(03:34:25 PM) Stephmw: wooops.

Next Page