Older blog entries for robilad (starting at number 53)

It ain't Java till it has the RCSID

I've walked up to the Uni today, and read a nice paper from the authors of a nifty static analysis tool for Java, FindBugs. It is a pattern matching based tool, that emmits warnings for popular problems in Java code.

The most interesting part for me was the comparison of bugs found in GNU Classpath, a free software implementation of class libraries for Java, and Sun's own, proprietary JDK 1.5.0. The authors compared classpath 0.08 vs JDK 1.5.0 build 59.

Classpath 0.08 is 457 KLOC, while JDK's rt.jar weighs in at 1,183 KLOC. That's about 2.5 times the size of GNU Classpath's code base. Using FindBugs, the authors found 724 suspicious constructs in GNU Classpath, but they found whopping 3,314 suspicious constructs in JDK's rt.jar. In other words, there are around 4.5 times as many potential problems with Sun's proprietary code as with FSF's free software implementation.

As a free software author, I'd argue that such an apparent quality discrepancy between proprietary and free software implementing the same tasks (core java class libraries), is rooted in the fundamental difference between open and closed software developement models: it is very easy for anyone to fix the bugs in Classpath and get their patches accepted by submitting them to our mailing lists or the Savannah patch tracker, while Sun's openly closed community source effort puts massive barriers in front of potential participants in form of NDAs, indemnification requirements, or even accounting regulations in the source code license, in case that you happen to need one.

As proprietary software goes, the JDK has its share of embarassing code. Check out Sun's programmers making first baby steps with revision control systems in their live code base, back in the mid-90s. Actually, the RCSID fields are in there in JDK 1.4, too. They are probably in earlier versions, as well. So if Sun's claims about their Java compatibility test suite are true, then surely some poor intern must have written tests for those vital parts of the JDK APIs. If you don't have the completely useless RCSID tags as protected fields you are not Java-compatible, right? Binary compatibility would break, and the ghost of 'Write Once, Run Anywhere' would come to claim your bytecodes.

Well, it's not like Sun really cares that much about binary compatibility all the time. All the WORA marketing talk aside, Sun has ocassionally bowed to the pressure of having to fix stupid design mistakes by, well, perpetuating them. Check out the last mouse event for now and for ever. Actually, the value of the constant has changed between JDK releases, as someone invented the mouse wheel without telling JDK developers about it. Instead of dropping the integer constants altogether in favor of an interface that's more flexible and may be able to cope with novel pointer devices without breaking binary compatibility each time someone adds a gadget to a mouse, Sun decided to, well, modify a constant.

Still, my favorite API blunder in JDK is 1337. It's the 53P4R473R from the land without code review, spell checkers, or both. This one has been with us since at least JDK 1.2. Long live Rite Once, Run Anywhere.

So, given all the 'will Sun ever open source their Java code' posturing, I can't help but wonder if I'd really want to deal with one million lines of code that has almost double the defect density of Classpath, with apparently abadoned parts happily bitrotting their way into JDK 1.5 without review. Maybe for those APIs where GNU Classpath doesn't have an implementation yet. But given that GNU Classpath doesn't really have a tradition of accepting poor code, I'd doubt the JDK sources would make it in, without some peer review. It could be the first peer review some of Sun's JDK source code would be getting since 1997, according to RCSID tags.

28 Jul 2004 (updated 28 Jul 2004 at 10:14 UTC) »
The Joys Of Not Having Access To The TCK

I've been trying to figure out what the precise terms of the TCK license in J2SE 5.0 will be for months now. Things are moving slowly, but it looks like Sun may eventually freebeerize the access to their J2SE TCK for 'qualified non-profit entities and individuals'. That would be a great gesture towards projects like GNU Classpath, that strive to be as compatible with the specifications as possible. It's not clear what the precise terms will be, though.

And that's why there are times when I am glad that Kaffe.org doesn't have access to the J2SE TCK. In particular when I look at the current pains some open source J2EE projects are having with their TCK access.

What's a TCK anyway?

A TCK is a 'Technology Compatibility Kit', a test suite for some Java technology specification. The TCK is like a binary oracle of specification compliance: an implementation passes the TCK, and poof! it is magically branded compatible.

Well, actually, for the magic to work, you need to license the TCK, and you usually do that by letting money work its magic. A J2EE TCK was hundred thousand US dollars worth, last time I heard.

TCKs for Free!

Fortunately, thanks to ASF's efforts, there is a nice Compatibility Testing Scholarship Program. The obvious catch seems to be that noone signed up, according to that web page.

J2EE Cert Is Money

That's not exactly true. Two open source J2EE servers, JOnAS and Geronimo signed up for the scholarship, while JBoss, being developed by a for-profit entity, failed to qualify for a free scholarship, and had to pay for the TCK license.

Finally, JBoss passed the TCK, and got certified. Chances are that Gueronimo and JOnAS will follow suit, too. And given that in the J2EE market a certification is an important seal of compatibility, it is a door opener to places that were reserved for non-free software before. Wonderful! Congratulations to JBoss developers! Thanks to Sun for supporting open source J2EE servers by granting them TCK scholarships!

Licenses, Pesky Licenses

Well, it would really be great if things were that simple. But then, there is always the controversional issue of licenses to spoil the fun. And, in all its glory, here it is, the 'NOTICE FROM SUN MICROSYSTEMS' that both Geronimo and JOnAS have on their web pages:

Any redistributed derivative work of the software licensed hereunder must be compatible and branded with the appropriate compatibility logo specified by Sun and licensed by Sun pursuant to a separate Trademark License required to be executed by you with Sun. Redistribution of the software licensed hereunder must retain this notice.

So what does this mean, in real life? It means that you can not redistribute a patched version, of course, unless you happen to be a TCK licensee and the patched version passes the TCK. It may also mean that you can not create packages of the software, as a package could be seen as a derivative work. But wait, it gets better.

Let's say you fetch an uncertified build of Geronimo. Would it be a 'derivative work' of a certified build? If so, are you allowed to redistribute it at all? Probably not, according to this notice.

Let's say you find a security problem in your J2EE server code and the fix uncovers a bug in the TCK. Can you distribute the security patch to protect your users? Probably not, according to this notice, at least not until the TCK is fixed.

And so on. The ASF has figured that out, and is trying to get Sun to reword the notice into something that's not contradicting the open source licenses of the code in question. ObjectWeb has a lengthy wiki page going into some legalese gymnastics of interpreting the LGPL to make it work with the 'NOTICE FROM SUN'. The ultimate answer seems to be that noone knows for sure who can distribute what to whom. Furthermore, for added enjoyment there is a bit of hinting on the JOnAS Wiki that Sun's legal department may feel like enforcing some of their patents or prosecuting potential trademark infringements if one redistributes intermediate, uncertified builds of a J2EE server.

As if that was not enough of legal uncertainity surrounding the poor Geronimo and JOnAS projects, a J2EE certification with the 'NOTICE FROM SUN' may turn out to be a one way street with respect to how the author can license the code. Interestingly, JBoss does not display such a notice, as far as I can tell. It may have something to do with JBoss not going through the scholarship, but buying a TCK license from Sun instead.

I hope the ASF can find a way to convince Sun to protect their trademarks in a different, less cumbersome way. I also hope that the J2SE 5.0 TCK won't come with such a 'NOTICE FROM SUN MICROSYSTEMS'. It would make having the TCK pointless if one would not be allowed to distribute the result, and allow people to redistribute it. That sort of thing simply does not work in open source.

But till then, if you're writing a J2EE server, you may want to consider holding off your TCK scholarship application until the 'NOTICE FROM SUN' gets reworded into something more socially acceptable.

No Meat For Me, Please

There is a whole side issue here, that Sun seems to have overseen. Some people may not be interested in sporting the Java trademark on their software for various reasons. Kaffe is not Java(TM). GNU is not UNIX(TM), and so on. The 'Business Terms' for the J2SE 1.5 TCK seem address that, by not granting any trademark license rights to qualified entities and individuals under the free beer program. That's one half of the story. The other half is not having GPL-incompatible 'STRINGS ATTACHED' notices with the TCK.

Advogato is back!

Everyone's favourite pond in the savannah has returned back to life. Now they are looking for volunteers to help out with mantaining the site.

Movies: Troy

Ah, what a dull work of art! It's almost as good as 'Gladiator' in wooden acting. The story is hacked together, and serves as a thin veil around Brad Pitt's major acting feature in this movie: his naked butt. But as showing Brad Pitt running around naked for three hours doesn't really cut it, there is some jumping around with swords, spears and bows thrown in, and a bit of subtext commentary on invasions for stupid reasons.

Unfortunately, they got the cast completely wrong. It feels like a school theatre group playing 'Illias' on a way too big stage. It only gets funny when it's ridiculous. The whole siege business is turned into a three week long bonfire party. So when the actors act up about the grim nature of war, and the movie tries to weave in a bit of subtext, it just doesn't work that well, when the siege looks like a boy scout day by the seaside.

10 May 2004 (updated 10 May 2004 at 19:25 UTC) »
Pulling a SCO for Fun and Profit

I've looked more closely at the SCSL, since the JavaLobby discussion was still rather unsatifying. This time around, I was interested in what implications SCSL has in real life. Anectodal evidence, in a way.

With something as broad as the SCSL, you probably don't want to scare your customers too much, so you go after a few selected targets. Sun has worked hard to make Java the COBOL of the nineties, i.e. the thing you use to do business. They have succeeded, as far as I can tell.

So I've looked at how Sun has used the SCSL in the Java enterprise field, against Lutris and JBoss.

While I have no inside information on the deals Sun struck with JBoss or Lutris, I do find both cases to be interesting, since they both involve using SCSL as the big stick to put licensees under pressure.

Let's look at Enhydra first. Back in 2001, Enhydra was a rather hip open source enterprise Java application server. It was the flagship open-source product from a small, but successful company. Eventually, Lutris had to pull the open source Enhydra enterprise application server off the web. There is the 'white-washed' press release story, that is all about an amicable agreement among partners. And then there is the story from the trenches that talks about some nice implications of J2EE's SCSL licensing for open source projects and how it can be nicely enforced.

Then of course, there is the big JBoss story from last year. We remember, back then, JBoss was a clean-room Java application server implementation (there is a bit of cute 'Lutris betrayed you' spin in that one).

Back then, Marc Fleury said: "Sun has never accused JBoss of violating any of their licenses, and JBoss is not violating any of Sun's licenses by distributing JBoss." And as JBoss grew stronger, and started to reap the benefit from Enhydra's forced demise, Sun apparently proceeded to the next item on their SCSL enforcement list. Et voila, we had the great flame fest between JBoss and Sun about J2EE TCK, compatibility and what not, until Sun finally invoked the SCSL.

All of a sudden, JBoss gave up the rhetoric, settled an SCSL 'incompatibility' and paid an undisclosed sum of money.

So, while bits and pieces from SCSL may seem like 'nonsense' Sun didn't really have problems in the past enforcing it against their (or their customer's) competitors. In both the Lutris and the JBoss case invoking the SCSL was apparently what broke the camel's back.

Back then, we didn't have 'pulling an SCO' to describe attempting to enforce 'funny' licensing statements, though.

One of the (many, I admit) claims in SCO's law suit was that IBM put code that IBM wrote independantly from SCO's code into Linux and thereby violated the contract they had with SCO.

While such claims seem ridiculous at first, the SCSL apparently gives whoever owns the Java IP the right to claim all sorts of 'funny' things over independant third party Java code.

Online communities and discussion style

My unfavourable dissection of SCSL has made it to the Javalobby front page. I have a deep understanding now why so many people who have something to say avoid the 'discussion board' communities like Slashdot. It's the 'my rightful anger is bigger than yours' discussion style that turns me off.

I'm wondering whether the easy accessibility of discussion boards invites more noise than mailing lists.

6 May 2004 (updated 6 May 2004 at 04:52 UTC) »
Successfully Marketing Vendor Lock-In

Marc Fleury, the JBoss dude, thinks that some open source is good, but some open source is really bad. Since Marc is in the "Professional Open Source" business, I wouldn't have expected him to consider open source to be a bad thing. Alas, when you've just convinced people to give you 1E7 USD in cash to burn, those poor pony-tailed idealistic developers from academia sure look like they are giving "Professional Open Source" developers a bad image.

Lucky me, I don't have the trade-mark hair-cut of free software hackers, like mjw, the GNU Classpath maintainer. I've got something else though: a few reasons to offer why Mr. JBoss might have decided that Sun's not so bad , after all.

You see, as Marc Fleury explains in his open-source-Java-slamming interview, JBoss has spend considerable resources working around bugs in Sun's Java implementation. They've had to play tricks with class loading and probably quite a few more ugly, out-of-spec things. And that shows.

When you take JBoss for a spin on a runtime that's not derived from Sun's code, like Kaffe, it breaks to pieces. It collapses under the weight of all those workarounds around broken Sun's code and underspecified APIs.

For example, JBoss will happily try to open XML text files using ZipInputStreams. Of course, the Java API specification demands that the ZipInputStream throws an IOException when it encounters bad data. Except that Sun's implementation violates the specification. JBoss relies on the broken behaviour: if you implement ZipInputStream according to the spec, JBoss will bail out as soon as it starts opening its XML files during loading.

That's where the 'free java fear factor' comes in: If you've locked yourself in into writing for a buggy implemenation instead of writing to the JDK API specification, anything that threatens the buggy implementation by implementing the specification correctly, threatens your business model.

If JBoss can not adapt to run on GNU Classpath, it'll have a hard time staying part of the "standard linux java enterprise stack".

That stack will increasingly run on top of gcj, Kaffe OpenVM or other GNU Classpath based runtimes. Red Hat is already shipping natively compiled Ant, Tomcat, Eclipse etc., eliminating the reasons why one may still need to download Sun's non-free software one by one. ikvm over Mono takes a different route to reach a similar goal.

Whichever J2EE server gets to run on Kaffe or gcj first, will be in the strong position to be bundled by default on Linux distributions from Debian to Mandrake. Given that JBoss has had to create workarounds around Sun's bugs for quite a while, I'd rather place my bet on legacy-free projects like Geronimo. They have less cruft that they'd have to rewrite or get rid of.

Is Java open source now or what?

James Gosling wrote in his weblog "If we do something to make Java even more open-source than it is already, having safeguards to protect the developer community will be something we pay a lot of attention to."

Well, I'm a curious person. I'm usually up-to-date with what's happening in the Java world, so I figured I must have missed the day Java became open source. Alas, I decided to put the great James Gosling to a test. My tools will be the Open Source definition version 1.9 and the Sun Community Source License version 2.3.

Since James talks about making Sun's Java implementation "even more open-source", let's see how open source Sun's code already is, by checking each clause of the open source definition against the SCSL.

Open Source Definition vs. SCSL

* Free Redistribution


* Source Code

Doesn't allow free redistribution, so redistribution in source code fails, too.

* Derived Works


* Integrity of The Author's Source Code

Doesn't allow free distribution of separate modifications either.

* No Discrimination Against Persons or Groups

I guess it passes that one, yay!

* No Discrimination Against Fields of Endeavor

Nope. Explicitely limits fields of endeavor to research, commercial use, or internal use.

* Distribution of License

Nope. The TCK license comes with what's effectively a NDA.

* License Must Not Be Specific to a Product

I guess it passes that one, yay!

* License Must Not Restrict Other Software

Nope. Once you've agreed to SCSL, you can't distribute non-compliant software. So you couldn't redistribute kaffe, gcj, or even more up-to-date versions of Xerces if they break tests in the TCK.

* License Must Be Technology-Neutral

Nope. It's a click-wrap license. It even has a pointless [ACCEPT] [REJECT] at the bottom

Total: 2 out of 10.

I'd guess that Sun's java implementation is slightly more open source than my Microsoft Windows 98SE installation CD-ROM. I haven't bothered to check the Microsoft Windows 98SE EULA, though, so I may be wrong.

Protecting Java developers with SCSL: The Top 5 Safeguards

But wait, there is more. The SCSL is a fascinating read if you're into mind-boggling legalese that's being marketed as 'sort of open-source'. I'll do you the favour and post the funniest bits and pieces on how the SCSL protects the Java developers.

Top 5: Debugging your Java code can violate the license

People often think that the SCSL is there to prevent forking and stealing of Java. That's not the whole deal, as the following exhibit from the SCSL shows:

GLOSSARY, 1:"Commercial Use" means any use (excluding Internal Deployment Use) or distribution, directly or indirectly of Compliant Covered Code by You to any third party, alone or bundled with any other software or hardware, for direct or indirect commercial or strategic gain or advantage, subject to execution of Attachment D by You and Original Contributor.

So let's say you're writing a J2SE application for a customer, and debugging it in one of those friendly IDEs that allow you to trace through system library code. You see in system code why it breaks, and discover there is some facet of the API that was not well documented in the J2SE docs, that breaks your code. You fix your code to work around it, and ship it to the customer.

Congratulations, you've just violated the SCSL, unless you've got a commercial license use with Sun, since your use of SCSL covered code is no longer limited to your company.

You'd need to enter a real, written contract with Sun, that costs hard cash, indemnifies Sun, allows them to inspect your bookkeeping, and a lot of other interesting things. Of course, the commercial license in Attachment D does not really allow you to debug Sun's code anyway.

Top 4: All Your Java Are Belong To Sun

GLOSSARY, 13. "Modification(s)" means (i) any change to Covered Code; (ii) any new file or other representation of computer program statements that contains any portion of Covered Code; and/or (iii) any new Source Code implementing any portion of the Specifications.

13(i) is your normal copyright law. 13(ii) is your normal copyright law with an extra spin: it tries to prohibit fair use by claiming that containing *any portion* of SCSL covered code turns your code into a modification of SCSL covered code.

Given that you're writing your code in java, chances are that any class you write shares a certain amount of text with some SCSLd covered code, simply because they are written in the same programming language. So 13(ii) covers pretty much all java code ever written by anyone who licensed code under SCSL. To put more graphically, GLOSSARY,13(ii) == All your Java are belong to us

Let's get to 13(iii), which is a little more convulted. It says any *new* Source Code implementing *any portion* of the *Specifications*. New code is quite obvious, so it coveres all new code you write. Then we have a clarification, it's any new code you write that implements any portion of some specs. "implementing any portion of specs" doesn't say 'extending Object is OK', it says "there are some specs, you implement any single bit out of them, your code is covered". Both the JDK API spec and the JLS cover java.lang.Object's method signatures. If your code extends java.lang.Object, it implements "a portion" of the JLS and JDK API, since you can call the methods covered by the Object API on it. If that's too far fetched for you, take classes implementing the Serializable interface, or your classes extending SCSL covered classes, and overriding methods in them.

But the really convulted part of 13(iii) is in the reference to "Specifications". If we look up "Specifications" in the glossary, we'll find

GLOSSARY, 21. "Specifications" means the specifications for the Technology and other documentation, as designated on the Technology Download Site, as may be revised by Original Contributor from time to time.

This clause gives the copyright owner (or whoever hacks the site) a backdoor to revise the specifications, and claim violation afterwards, even if you were compliant originally. The license does not specify the "Technology download site" precisely (with some URL) anywhere. It does specify the community source download site, but that one has no JDK specs. Beautyful.

Top 3: Shut up, And Don't You Dare To Write Tests

One of the cute things about Sun's Java implementation is that Sun has apparently written a huge set of test cases to verify the conformance of their implementation to the API specification. At least that's what the rumour says. If someone who licensed the TCK would really tell you if Sun's own VM passes the tests, he'd have to kill you, according to the license.


b) TCK Use Restrictions. You are not authorized to create derivative works of the TCK or use the TCK to test any implementation of the Specification that is not Covered Code. You may not publish your test results or make claims of comparative compatibility with respect to other implementations of the Specification. In consideration for the license grant in Section 1.a above you agree not to develop your own tests which are intended to validate conformation with the Specification.

That's a NDA, as far as I can see it. You can not talk about your TCK results. You can not say that you're more TCK compatible than Sun for example, even if it was true. Noone can check how TCK compatible Sun's implementation is, and publish their findings.

So you can't take IBM's and Sun's runtimes and see which one is better wrt to TCK compliance on your particular system. Now you may be asking: why should I care, Java works everywhere ?

Except that it doesn't. It usually takes me a few minutes to crash Sun's. I bet it passed the TCK on the particular operating system version they tested it on last year, but operating systems change, security patches get applied, and whoops, the rock-solid JVM is no more rock-solid. But you can not test your client's specific os+vm setup with JDK TCK and share that information with your client, without breaching the TCK license. Beautyful.

On a side note, I especially appreciate the 'you may not write your own tests' clause. If you write your own test to find a bug in Sun's code that violates the spec, and submit a bug report to the BugParade, and have licensed the TCK, you've breached the license.

Top 2: Show Me Your Code, Or Else

Beside claiming ownership to all the code anyone who licensed the J2SE code from Sun, the SCSL has also a second ace up its sleeve to protect the mean Java developers from themselves: requiring access to all your extensions' interfaces. With your TCK due in 90 days. Or else.

3.e) Extensions. (i) Covered Code. You may not include any Source Code of Community Code in any Extensions; (ii) Publication. No later than the date on which You first distribute such Extension for Commercial Use, You must publish to the industry, on a non-confidential basis and free of all copyright restrictions with respect to reproduction and use, an accurate and current specification for any Extension. In addition, You must make available an appropriate test suite, pursuant to the same rights as the specification, sufficiently detailed to allow any third party reasonably skilled in the technology to produce implementations of the Extension compatible with the specification. Such test suites must be made available as soon as reasonably practicable but, in no event, later than ninety (90) days after Your first Commercial Use of the Extension. You must use reasonable efforts to promptly clarify and correct the specification and the test suite upon written request by Original Contributor. (iii) Open. You agree to refrain from enforcing any Intellectual Property Rights You may have covering any interface(s) of Your Extension, which would prevent the implementation of such interface(s) by Original Contributor or any Licensee. This obligation does not prevent You from enforcing any Intellectual Property Right You have that would otherwise be infringed by an implementation of Your Extension.

Basically, this means your extension's specification must be published "free of all copyright restrictions with respect to reproduction and use", and so must be the TCK, i.e. the test code for your library. Why Sun fails to provide their TCK under similarly liberal terms is a very interesting question.

Anyway, for some added fun, 3.e.iii prohibts enforcing the GPL on your Java libraries if you agree to SCSL.

Top 1: All Your Libraries Are Nothing But Simple Extensions

Oh, and of course, the term Extension is so broadly worded that it covers all Java library code licensees ever wrote:

9. "Extension(s)" means any additional classes or other programming code and/or interfaces developed by or for You which: (i) are designed for use with the Technology; (ii) constitute an API for a library of computing functions or services; and (iii) are disclosed to third party software developers for the purpose of developing software which invokes such additional classes or other programming code and/or interfaces. The foregoing shall not apply to software development by Your subcontractors to be exclusively used by You.

(i) covers all java code, (ii) reduces coverage to exported (i.e. public/protected) members, (iii) reduces coverage to libraries.

Unless the library code you ship to your clients consists of package-private classes and methods, you have to disclose your APIs and *write a freely available TCK* for it. I've never seen such things for most of the Java code out there, which strikes me as mildly weird. If the SCSL is so cool, you'd expect a lot of people documenting their "extensions", no?

Bonus Top For Consultancies: Keep Off The Javax

Oh well. So you decide to give up writing Java library code just to have it owned by Sun, and go into consulting to sell code other people wrote to your clients. No go, the SCSL has a weird package naming clause, that doesn't allow you to use what Sun considers to be its own namespace turf.

3.e.(iv) Class, Interface and Package Naming. You may not add any packages, or any public or protected classes or interfaces with names that originate or might appear to originate from Original Contributor including, without limitation, package or class names which begin with "sun", "java", "javax", "jini", "net.jini", "com.sun" or their equivalents in any subsequent class, interface and/ or package naming convention adopted by Original Contributor.

The great thing about that clause is that it actually prohibits the distribution of J2EE servers with Sun's JVM by licensees of J2SE source code under SCSL.

A J2EE server implements packages in the javax namespace by definition. So going from 'start enterprise Java consulting' to 'jail' takes three simple steps:

  • Step 1: license J2SE source code under SCSL
  • Step 2: Distribute JBoss to your client with Sun's JVM
  • Step 3: go to jail for voilating 3.e.iv.
Keep Trying, James

A license that's so broadly (and poorly, in my opinion) worded that it allows such (unintentional, I assume) interpretation should be reworded in a cleaner fashion, really. It's very, very far from open source. It doesn't even protect Java developers from anything, it just puts them under extra legal risk, and makes abstruse claims of code ownership, not unsimilar to those of SCO in the IBM case.

While I don't think Sun's management would try to enforce the SCSL to the letter, it would be quite funny if Microsoft bought Java from a bankrupt Sun, and then went ahead to enforce the SCSL against developers who accepted the license if they wouldn't switch to dotNet.

Meanwhile, ...

There was a new GNU Classpath release that looks very good. A new Kaffe OpenVM release is in preparation, too.

No "safeguards", there, though. We couldn't make either "even more open-sorce" then they already are, being licensed under GPL(Kaffe) and GPL+linking exception(Classpath).

Kaffe OpenVM

Helmer and Guilhem are working their way through interesting bugs in the core. I'm meanwhile syncing Kaffe up with GNU Classpath's latest changes, and contributing some small fixes back. Thanks to Eclipse, I got quite a few imports cleaned up, so that's slowly going back into GNU Classpath.


"Triplettes de Belville" was quite enojable. Good music, straight story, nice refences to Tati, a few good jokes.

Kaffe OpenVM

Well, tempus fugit, and all that. In the last three weeks we got a few new developers on board. There is doogie, who has almost single-handidly beaten a few thousand warnings into the ground last week. And there is Jim Huang, who's been testing a lot of interesting stuff with Kaffe in preparation for an interesting Kaffe Multi-Media Project.

Thanks to jpick, we've got a release plan for 1.1.5. It's due in three weeks. As usual, there is a ton of things I'd like to see happen before the release. I've been hacking on A,C,F and I from that list, and it looks like I'll be able to get gjdoc into kaffe very soon now, mostly thanks to efforts from Arnaud Vandyck on integrating libxmlj into GNU JAXP.

In other news, Guilhem has been quite busy recently fixing kaffe's kjc, java.text implementation, NIO, and almost everything else he could get his hands on. He's a great hacker to have on board. I was also pleased to see Helmer return with a series of patches, to improve ARM support, among other things, and Ito tracking down a few ugly bugs.

44 older entries...

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!