Older blog entries for robilad (starting at number 73)

Linking with the Qt4 libraries using Autotools

I've done the initial build system for the Qt4 peers in GNU Classpath using the Autotools. mjw improved on it, and fixed some rather ugly $SED-usage in my original solution.

Since Qt4 is just fresh out of the door, and has the appeal of being *the* professional, free software cross platform toolkit for developing desktop applications that run well & look nice on all major desktop platforms (Win32, X11, Mac OS X), it's been fun to see people reporting sucess getting the Qt4-based GNU Classpath peers working nicely using Kaffe OpenVM on GNU/Linux & Mac OS X. Noone has tried it yet on Windows, afaik, and Kaffe could use a Windows developer or two to make it shine there as well.

Anyway, it turns out that GNU Classpath's Qt4 detection & usage build machinery just became the topic of a discussion on the autoconf mailing list. So now the libtool, autoconf & automake developers are dissecting the build machinery a bit further, and proposing improvements. Fun to read, if you are into using autotools.

I posted a detailed tour of the code in configure, and there are a few comments suggesting improvements to the code in GNU Classpath in the thread. If you need to use Qt4 in your autotools projects, it's an interesting thread to go through.

Using the LGPL for Fun and Profit

Since it's the time of the year for TheServerSide's ritual J2EE vendor licensing brawl, I figured that I should try to see if I can profit from the fear of the LGPL.

So far, no millions of dollars have magically appeared on my account, though. Back to real work, I guess.

Kaffe OpenVM

Some more good news. Riccardo reports that Kaffe is running well on sparc-solaris again, I've received some good looking screenshots of Kaffe & Qt 4 peers from GNU Classpath on Mac OS X, and ... Eclipse 3.1 on Kaffe's CVS HEAD actually worked reasonably well for quite a few things, including downloading updates, running CDT 3.0 and random playing around with it. I could not get the profiler to work instantly, though.

But I still prefer GNU Emacs for real work.

25 Aug 2005 (updated 25 Aug 2005 at 14:24 UTC) »
Kaffe OpenVM

Things are going nicely ahead. Last night I fixed the location of the dreaded, largely useless tools.jar file to be found where some popular build tools expect it. Ant, for example, if it can't find tools.jar, will print out a warning. Maven 1.0.2 will roll over in disgust and quit. The latter has been brought to surface by trying to build Geronimo 1.0M4 on Kaffe, so I decided to fix it for good.

The funny thing is that neither of those tools should actually need much from tools.jar when running on Kaffe. None of the undocumented com.sun.* entry points for JDK tooling classes are there in Kaffe. Because it's not the JDK, after all, so it does not need to carry around the undocumented legacy of it. ;)

Nevertheless compiling Java source code with ant and maven on Kaffe "just works", without the user having to pass additional build.property definitions to ant.

The secret to making it just work is in presetting the expected properties right in the VM. Rather than either chasing after ant developers, who are in turn chasing Sun developers' undocumented interfaces, or reimplementing those undocumented interfaces from scratch and hoping that Sun will commit to keeping them stable, Kaffe simply sets the properties ant cares about to values that match its current configuration.

Right now, that's build.compiler, which is preset to jikes. The user can override that by explicitely setting a different build.compiler through ant. Coming next is presetting build.rmic to kaffe for seamless rmic task execution in ant using the classes from cp-tools and ASM.

I still have a CLASSPATH issue to sort out before the ASM-enhanced rmic works. And then Lucene will hopefully go to Debian's main archive.

In other news, Riccardo has decided to start to blog. The nice thing, beside some good news on Kaffe on Darwin, is that his blog links to his devianart page, which has a collection of photographs portraying life in northern Italy. I'll take a break, and enjoy some of it.

OSCON article fallout

Since tromey talked at OSCON a few weeks ago, about the state of free runtimes, and Geir talked about Apache Harmony as well, I saw an eWEEK article mentioning the talks, and summing up some basic ideas.

One of the intersting points for me is the author's concern for Sun Microsystems "struggle" to keep control of Java. I've seen that mentioned a few time recently, as gcj and other free runtimes are shaping up really nicely these days, and some people are seemingly afraid of a world in which Sun Microsystems does not control Java(TM) any more.

The truth is, since Java(TM) is just a funny little trade mark red-blue coffee cup logo, and Sun Microsystems is not going to ever give up their trade marks, Sun Microsystems is never going to lose control of the funny little coffee cup logo.

Neither is Sun Microsystems suddendly going to lose control over the source code of their proprietary implementation of the Java programming language and virtual machine specifications, unless they desperately want to. There is no indication of the management of Sun Microsystems ever wanting to do that, either. Not in the past 10 years, not in the future.

Neither can Sun Microsystems lose something it never had and can not buy: control over gcj, Kaffe, GNU Classpath or Apache Harmony.

So, whenever I see the "Sun will lose control of Java because free runtimes will end up being better and more popular!" argument, I have to chuckle. That's like saying that Microsoft will lose control of C++ because g++ is much better and more popular on most platforms than Visual C++ (or whatever it is called these days).

Movies: Immortel (ad vitam)

Like most comic book adaptations, I'd put it in the "Born to Be a B-movie" category. Somewhat surprisingly to me, this one did not suck so badly, probably because the comic books' author also did the directing and writing, some twenty years after the original comics appeared. So it has some of the force and pace of a graphic novel.

The movie is about an Egyptian god coming down to a late 21st century New York in a hoovering pyramid to try to impregnate a specific, blue haired alien woman slowly turning human, using the more-or-less willing help of a rebel guy's body. Whatever.

Despite the weird background story, the visual work nicely carries the film forward. There are just a few rather badly done CGI models, and in general, a lot of attention was given to computer generated dirt & detail. The whole film has a nice "Blade Runner meets Fifth Element and they go to watch Sky Captain together" feeling to it.

For a comic book going to screen, that could have been a lot worse. Viewable without side effects in combination with alcoholic beverages.

KDE-Eclipse

Among the more funky things I spotted recently seems to be a SummerOfCode project that allows nice things from the Autotools school of thought, something that has been discussed recently on the #classpath IRC channel in light of making it easier to hack on GNU Classpath using Eclipse.

The feature list reads really nice. Now that Eclipse 3.1 works nicely out of the box on Kaffe OpenVM's CVS head, thanks to tromey's assistance in hunting down shared library name mapping issues in class loaders (don't ask ;), I'll give it a try, the new CDT release and the Eclipse TPTP tools to see how well the JVMPI interface in Kaffe works with that. There are a few performance issues that I'd like to track down in Kaffe.

I've thrown a GNU Classpath build at Eclipse on Kaffe last night, and it worked fine, though not blazing fast. I've also thrown FindBugs on GNU Classpath in Eclipse on Kaffe, and that held up nicely as well.

I think the current CVS head is shaping up nicely for a release. A few more things need to be done, like merging in ASM, Antlr, fixing the majority of compiler warnings and Debian bugs, and it should be ready to roll.

Cleaning up a bit after the Harmony announcement

As half the Slashdot surfing world has probably noticed, there is a new proposal for an Apache project to implement a VM and a set of class libaries, and all that under the Apache umbrella.

Ok, as I am involved in both in Kaffe OpenVM and GNU Classpath, which do pretty much the same thing, and my name is on the list of people who said they'd be interested in committing to an apache licensed implementation as well, ... you may be thinking that there is something pretty crazy going on involving huge amounts of free crack straight from the Sun headquarters as the Apache license version 2.0 and the good old GPL version 2 do not mix well. Well, it's not really that hot material for conspiracy theories.

First of all, what's happening? Well, the some people within the Apache Software Foundation, an organisation that's been quite successful at writing, maintaining and encouraging donations of Free Software written in the Java programming language eventually started thinking that a full J2SE implementation might be a good thing to have under Apache's umbrella as well, beside a huge chunk of the stack above it.

I guess working up with Kaffe and GNU Classpath developers to work on making GNU Classpath work well on the latest CVS snapshots of various free software using Apache's Gump as a permanent regression test engine has probably encouraged people to dip into the GNU Classpath runtime community. Hacking on VMs and class libraries is fun, and the GNU Classpath developers are a great bunch to work with (and party).

While I guess that idea has been going on for a while in the Apache community, my impression is that due to the sheer size of the task, people initially expected some donor to show up, and develop code collaboratively, rather than doing it all from scratch. That obviously did not happen in the last 10 years so my impression might be way off. But for all the rumours about three-letter vendors releasing their runtimes as Free Software, the ASF would have seemed as the logical partner to team up with, for all the ASF's good working relations with those vendors.

Meanwhile, something happened. Some of us witnessed the literal rise from runtimes like Kaffe out of ashes in the last two years due to an increasing amount of cooperation of Free Software runtimes around GNU Classpath as an efficient, quickly growing backbone.

So, pretty rapidly we're getting somewhere. Kaffe and Gcj are getting good enough for distributions like Debian, Ubuntu and Fedora to start shipping normal java applications, because increasigly stuff just works. In fact, it is actually starting to work increasingly well.

Beside just the cooperation on the class libraries, tromey and I have talked a bit on an off on GNU Classpath mailing lists and IRC about getting the verifier from gcj merged into Kaffe, as it would seem to make sense to get one verifier right and collectively maitain it, rather than maintaining several ones. Along the same line went some ideas to revive the kaffe gcj bindings now that gcj4 offers binary compatiblity. Which eventually ended up in the general idea of turning a VM into a set of losely coupled components with clearly defined interfaces for people to plug into. Not that it hasn't been done before, I know.

There is not much code for this yet, but the current Kaffe-gcj bindings could eventually serve as one possible blueprint for such interfaces for execution engines, for example. The multiple garbage collector integration work in Kaffe done by Guilhem could serve to find out what GC interfaces one needs, and so on. Contributors to make these things happen right now would be very welcome.

So, during my recent trip to CafeBrasil, I had the opportunity to see a beatiful coutry, with wonderful energetic people, who were very enthousiastic about Free Software. I also had the opportunity to talk a bit about Kaffe, GNU Classpath, gcj, and how it all fits in and works. I believe we have something great going with GNU Classpath, that links so diverse projects as Mono, and JNode, SableVM and JikesRVM.

I also had the opportunity to talk about the VM-component interface ideas with people outside GNU Classpath, in particular with Geir from Apache. A modular VM platform would make it easier to get one's VM going, and that sounded interesting, given ASFs lack of a runtime. I also proposed to Geir adopting IKVM and thus Mono into the Apache tribe, but that's not how the ASF works.

For someone unfamiliar with the consensus, procedure oriented style the ASF goes after doing things, coming from the 'let's get things done the obviously right way' school of thought, the way the ASF works can seem a bit bizarre. There are committees. And roles in them. And something that amounts to a soul searching phase that happens during the consensus build up. That's not a bad thing, but it may confusing to watch.

In this case, some people from the ASF and the FSF have begun talking to make the Apache license GPL compatible, and adressing ASF's concerns regarding the LGPL. Kaffe provided an initial reason for people to get together, as some components from Apache (kerberos) would be interesting missing complement parts to Kaffe, and it would be interesting to try to leverage Apache's Portable Runtime to abstract some of the platform specifics away.

Alas, Kaffe being an independent project, neither FSF nor ASF really had a case at hand to more effectively discuss the things, so by ASF wanting to work on a Classpath runtime, the both organisations have a stronger focus towards the goals. At least I'd hope so. ;)

Ok, now, the way those things work can also be very upsetting. I didn't have a chance to see the announcement before Geir sent it out to the PMC list. So I guess it's easy to imagine my surprise on IRC when questions started flowing in. WTF?? WTFFFF????? Where Is The Free Crack???? sort of questions. And with a good reason.

The way the proposal is stated, it sounds as if Apache will just out of nothing, with people's help churn out a full J2SE 5 environment, all things included, because some of the existing code is not licensed under the Apache license. Having developed a strong Anti-NIH stance hacking on Kaffe, I can with a certain amount of assurance say that implementing j2se 5 takes years of a dedicated team to get the VM somewhat useful and then again another bunch of years to get the class libraries implemented. There is a reason why Kaffe, gcj, essentally everyone in GNU Classpath runtime family who one had their own class library either got rid of it, or merged it with GNU Classpath. The reason is that implementing all of J2SE 5 class libraries on one's own in spite of a liberally licensed FSF implementation is for most uses I can think of pointless.

The same goes for VMs in general, I think. GNU Classpath has more than 20 differnt runtimes using and contributing to it. So the natural choice seems to be to me for Apache to pick one and bless it eventually. That didn't happen because that's not how Apache seems to work: there first needs to be a concensus on who, what and how before such a decision can be made. And given that procedure, no VM could have been picked, so the dicussion proposal says 'make one's own'.

What the hell am I doing there, then, not being an Apache? Well, two things: a) trying to help bring ASF and FSF closer together, and ASF using and contributing to FSF's class libraries would be a pretty good thing to happen no matter which path towards a runtime they chose, and b) the ASF can reach a wide audience among developers programming in the Java programming languge that so far has either not heard, or been sceptical about Free Software runtimes based on GNU Classpath. For whatever reason the ASF seems to evoke much less fear and terror in some circles than the FSF, which may make working with those circles through the ASF easier.

Kaffe 1.1.5 out of the door

This is already a bit of old news, as jpick and me pushed the release out last week, before I headed off to Brasilia for CafeBrasil to talk continuously for a week or so about Kaffe OpenVM, GNU Classpath, GNU gcj and all that. 1.1.5 is notable for being the 'Duke Nukem' of Kaffe releases, the one that was 'coming soon' for a loong while, and finally made it into a nice, big, fat release.

In the year since Kaffe 1.1.4 was released, the lines of code count more than doubled, with around one million new lines of good source code from the various upstream projects, like GNU Classpath, GNU JAXP, GNU Crypto, and gcj The merge with GNU Classpath is now almost finished, with around 20 files left over to switch. That means we're almost 99% there, finally. It's been a long ride, and now we have a new shiny AWT implementation based on gtk, and the GNU Classpath 'good-looking' Swing working out-of-the-box in kaffe, just like all the various integrated upstream projects, like Tritonus for sound support, GNU Crypto for JCE, Jessie for JSSE, GNU inetlib for URL handlers, etc.

My plan for the future (i.e. this year ;) is to turn Kaffe from a melting pot and integration hotbed of class library development into the same 'bleeding edge' intergration facility for virtual machine components. Some work on that has begun on Kaffe's core, and ultimately the idea is to be able to plug in parts of other excellent runtimes, like gcj, or JamVM into Kaffe and vice versa. If it works out, it will turn into a GNU Classpath VM framework, that would allow people to bootstrap their VM from state-of-the-art spare parts.

Of course, now that I've spent more than a week away from CVS, I've seen that those amazing Classpath hackers have pushed further ahead and added a lot of new exciting code, like a unified IO encoder/decoder framework, and progress on CORBA and Swing. It's great to come back and see a huge lump of nice code sitting in the CVS ready for merging. Thanks a lot to everyone hacking on Kaffe and GNU Classpath, you folks seriously rock.

Assimilating NetBeans from Within

Continuing on the path to world domination for GNU Classpath using runtimes, the necesaary steps have been made to make Kaffe's CVS head work within NetBeans 4. It turned out that I just had to make Kaffe output -version information in a suitably JDK-ish way for NetBeans to be able to parse it.

While still only running on non-free software, it works suprisingly well as a way to use Kaffe to build and run Java programs that will work on free software. In all its glory it looks like this.

This is the first step towards getting NetBeans to run on a fully free software stack and smashing yet another Java trap. Thanks to Tim Boudreau, the NetBeans lead for talking me into playing with it. I hope some NetBeans hacker takes it up from here, and makes it possible to build, run and distribute NetBeans on a fully free stack.

17 Mar 2005 (updated 17 Mar 2005 at 19:30 UTC) »

Welcome to the Java Melodrama Show!

Today's headlines in the Java world herald the arrival of nothing less than a new era in Java ... licensing. The latest announcements from the innovative leaders in both proprietary and open source software license production, have been brought to the general blogging public today via a widely reported teleconference. Sun announced that they will announce yet another license for their source code later, maybe. In the long standing tradition of sweet license names like "scuzzle" or "cuddle", the new license will be pronounced "jewel", and written as JIUL.

So what's wrong with the current license, SCSL, cuddly nicknamed scuzzle and a jewel in Sun's crown? Hailed by Sun on its arrival back in 1998 as a blend of the best aspects of the proprietary and Open Source license models, the license failed to gain support, and has been widely debunked as as far from being open source as it gets without explicitely writing a license that violates each and every clause of the OSI definition.

After announcing that they will switch away JINI from the dreaded SCSL, Sun are now considering moving away from the SCSL for Java as well. In the words of Graham Hamilton:

"I expect SCSL will fade out. We're probably not going to do (J2SE) 6.0 under SCSL," Hamilton said.

Still, Hamilton believes the license is superb:

[SCSL] was intended to be the wonderfully perfect license, designed to cover all cases," Sun VP of Java Graham Hamilton said. "The problem was, everything was all wrapped up in one enormous license, and if you would hire battalions of lawyers, you would find that the license was great. The trouble is, most people don't want to hire battalions of lawyers and find SCSL is too complicated, so there hasn't been much adoption."

Hear, hear. The SCSL 'too complicated'? Most people don't want to hire an army of lawyers? How bizarre! What would James Gosling say to that?

""It's amazing how complicated most open source licenses really are," Gosling said. "And there's a growing number of them -- and they're all hard to decipher. Maybe I'm just an amused armchair quarterback, but I think it's funny, sitting where I am, having watched Sun get all the grief for supposedly complicated licenses, when you consider how truly gnarly some of these open source licenses are. They started out simply, like the BSD license, then the Stallman license ... then they all kind of swirled together. Now some of them have 'contamination' clauses in them -- the GPL is the poster child for that," Gosling said.

There you go: SCSL is just 'supposedly' complicated, with your handy 'battalions of lawyers' you should be able to decode it just fine, so what's your problem? Don't have an army of lawyers at your disposal? Sheesh. No wonder commercial Java users have trouble understanding you funny open source 'advocates'.

"By and large, they're actually somewhere between uninterested and hostile to the sort of wild and wooly world of open source," Gosling said.

And don't forget, kids, it's the open source licenses that are 'truly gnarly', not the other way round!

In fact, all those wild and wooly open sources are just causing so much trouble to poor companies:

"They're causing so much chaos in companies, who tell me: "(Open source licenses) are just too vague. I can't tell you what they mean. A court of law couldn't figure this out.' It's just a mess, and they're going to be a heartache for years to come."

And, besides:

'Gosling questioned the value of some existing open source licenses, such as the Gnu General Public License."A lot of the open source licenses are not very well written," Gosling said.'

It's them! Look there! Over there! The open source licenses are complicated and vague and ill written! Not the SCSL! Why can't you people see what's good for you: An army of lawyers! :)

But fortunately, someone is there to the rescue from that crazy, mad open source chaos and anarchy. Never missing an opportunity to desperately try to rub a bit off the street credibility from the 'wild and wooly' open source world onto the proprietary implementation that he helped create, 'Gosling described Sun's approach as "closed open source."'

No kidding. I'd describe it as "try all possible closed source licenses randomly till you stumble into one that fits by accident, while desperately pitching it as 'open source' to whoever will still listen", but what do I know anyway, I just get to see the impressive end results of Sun's approach.

So, on to the new licenses. In a brave effort to simplify the licensing of the Java technology, Sun created not one, not two, but 3 (in words: three) 'new' licenses to govern different fields of use and goals. That's a pretty impressive and unique effort at simplifying a software license by creating more clones of the same.

One of them is of course every Java researcher's favourite JRL license, which has, despite being a huge flop ever since it was introduced in 2003, been repeatedly re-pitched every few months as 'new'. The other 'new' license is the JDL, which is also not that new any more, and is just another SCSL-clone with the most obvious problems papered over.

The only really new thing that was announced today was that Sun will announce the third 'jewel' license sometime next month. Apparently that license will allow for internal use and modification. While Hamilton calls that 'an experiment', he also has a few words of warning for those that are too eager to take that offer literally:

"There's a lot of scope for companies getting into trouble if they get too enthusiastic about making their own versions of J2SE," Hamilton said. "We don't think it should be our job to tell them what risks to take."

Play it safe, kids. Don't get too excited, and you'll be all right.

And that's all for tonight, on the Java Melodrama Show, we'll finish with your moment of Zen:

Gosling described Sun's approach as "closed open source."

22 Feb 2005 (updated 23 Feb 2005 at 01:07 UTC) »

Ever since Sun's 1.5 (or 5.0, or whetever their funny marketing division decided to call it these days) came out, I've been wondering what the actual terms of access to the compliance test suite will be.

I was pretty disappointed when it turned out to be a mostly useless 'Read only' license. Judging by non-existant mailing list traffic on Sun's jck's project mailing lists, noone bothered to take Sun up on that offer for all the obvious reasons. I guess it was meant to be as yet another useless Sun PR stunt anyway, as Sun's Chief Java 6 dude, Graham Hamilton, happily ignored all comments made by me about the TCK release on his cutsey blog on java.net. Awesome display of skill in avoiding engaging in a dialogue there, I must admit. Calvin Austin, who brought Java 1.5 to life, had a lot more style, but he doesn't work for Sun any more.

Alas, beside having a licensing division that regularly churns out funny licenses, and a marketing division that has problems refraining from applying the term 'open source' to clearly non-open souce software like JAI or ImageIO, Sun also has a something pretty cool: a TCK Scholarship for 'qualified individuals' and organisations. ObjectWeb and the Apache Software Foundation went through that scholarship dance to get the J2EE compliance test suite, and ObjectWeb's Jonas has recently passed the tests. Encouraged by those successes, and by a lot of good conversation with Javali's awesome Bruno Souza, and Sun's energetic Onno Kluyt, I have sent in my TCK scholarship application, so that we can eventually have mutual compatibility between Sun's proprietary implementation of the Java specifications and Kaffe and other GNU Classpath virtual machines and runtimes.

This is the first step. Onno has acknowledged receipt of my application from Sun's side, so it's now up to the TCK Scholarship Board to decide if the Kaffe/Classpath application is worth support. Then it will be up to Sun to propose the terms for such access.

The application looks like this:

COMPATIBILITY TESTING SCHOLARSHIP APPLICATION FORM

This form is for applications for no-cost access to TCKs for Sun-led JSRs in the Java Community Process. Please read the requirements for qualified efforts which can be found at http://java.sun.com/scholarship/.

Send the completed form and any supporting documentation to: tck-review-board@sun.com.

Section I. Identification

I.a Name of organization: (leave blank if applying as individual)

I.b Address: (leave blank if applying as individual)

I.c Contact person: The TCK Review Board requires a single point of contact for the applying organization.

Dalibor Topic

I.d Address: [snip]

I.e Email address: robilad@kaffe.org

I.f Phone number: [snip]

I.g Fax number:

[snip]

I.h Request is for organization or for individual: Organization / Individual

Individual

Section II. Status Information

For organizations: (leave blank if applying as individual)

II.a Describe the legal status of your organization.

II.b Provide a link to or describe your organization's bylaws.

II.c Provide a link to or describe your organization's decision making process.

II.d Describe the nature and source of your organization's funding.

For individuals:

(leave blank if applying as organization)

II.e Employment information:

- Employed by:

- Freelance:

- Self-employed:

- Other:

Student at the Universitaet des Saarlandes, Saarbruecken, Germany. Student assistant at the Max Planck Institut fuer Informatik in Saarbruecken, Germany.

II.f Are you applying as individual contributor to a group effort: Yes / No

Yes

II.g If yes, describe group

Kaffe.org is a project implementing a free software virtual machine.

I'm one of the current leading contributors to the Kaffe.org project.

Kaffe.org cooperates with many other free software projects in its area.

It successfully acts as a melting pot for integration of various free software efforts related to the implementation of tools and libraries which are useful in the context of the java programming language.

Among the projects Kaffe developers cooperate with are

I am looking into collaborating with other projects implementing parts of the class libraries specified by JSR 176, including:

Kaffe.org is being developed in an open, collaborative fashion by a diverse group of core developers and contributors since 1996. All of the development communication takes place in the open on publicly accessible mailing list, and IRC channels, with daily snapshots available from cvs, ftp and through various websites.

A lot of the code in Kaffe comes from generous contributions by other free software projects, with whom I'm very pleased to have the opportunity to collaborate, sharing bug fixes and improvements.

For quality insurance the various groups collaborate on the free software Mauve test suite which contains more then 25.000 tests and various modules for testing core class library implementations, byte code verifiers, source to byte code and native code compiler tests.

Mauve also contains the Wonka visual test suite and the Jacks Compiler Killer Suite.

All tests and test results are openly shared between the various groups which use the results to improve their compatibility with each other. Mauve is distributed under the GPL.

I hope that one day it would become possible to combine the tests and results of the TCK with this larger effort to create a truly open compatibility kit, available to anyone, anywhere to freely evaluate compatibility claims.

Besides these regression and unit tests the Kaffe.org project is involved in real world application testing such as Eclipse, Jonas and the Apache Jakarta suite through Apache Gump running on Kaffe at http://brutus.apache.org/gump/kaffe/ . Kaffe.org is one of the most widely distributed environments for execution of Java applications on many GNU/Linux distributions and other free software operating systems.

Section III. Project Description

III.a Name of project: Kaffe.org

III.b If applicable, web site or url: http://www.kaffe.org

III.c Description of project:

Kaffe.org is a free software project that is implementing a virtual machine, class libraries and development tools to allow execution and development of programs written in the Java programming language.

Kaffe is licensed under the GNU General Public License. Parts of it are licensed are different, GPL-compatible, free software licenses. It doesn't contain any source code from proprietary implementations.

Kaffe is a very portable, modular runtime that has been ported to more than 50 different platforms. It runs on alpha, arm, ix86, x86-64, ia64, mips, m68k, sparc, sh, s390, pa-risc, and powerpc architectures, and on operating systems ranging from GNU/Linux, NetBSD, FreeBSD, OpenBSD to RISC OS, Cygwin and Solaris.

It has several execution engines, allowing for lean and fast Just-in-Time compilation on many platforms. Its performance is in general among the best free runtimes, and is expected to improve further as improvements from various Kaffe forks are merged back in into the main tree.

For class libraries, Kaffe has chosen GNU Classpath, and work is under way to fully convert Kaffe to use GNU Classpath out of the box. GNU Classpath currently implements around two thirds of the J2SE 5.0 APIs according to the japitools comparison page at http://www.kaffe.org/~stuart/japi/htmlout/h-jdk15-classpath.html. Kaffe is now, save for two dozen classes, using GNU Classpath for its core library. It also includes code from the other projects mentioned above that implement other parts of the J2SE APIs which have not been contributed to or implemented in GNU Classpath yet.

As the number of implemented classes and methods grows steadily, it is becoming more and more important to ensure compatibility between different runtimes. So this effort would be directed at fixing the compatibility deviations in existing code, and ensuring that new code complies with the specifications.

III.d Schedule. Describe the timeline for the project, eg when is the anticipated ship date, what stage is it now (alpha, beta, early access etc):

Kaffe 1.1.5 is expected to be released in February, and following releases will follow a two month cycle. The TCK passing release would become Kaffe 2.0.

Section IV. TCK

List the JSR(s) you are requesting TCK access for. Indicate for each whether you are also requesting to receive support:

JSR 176. Yes, I'd like to receive support.

This process is new to all of us in the Kaffe community so any advice or assistance is greatly appreciated.

Section V. Additional information

Provide any additional information or links to web sites or documents that may be helpful to the Review Board in considering your application:

I hope that the work on creating a free software, fully compliant Java implementation can be conducted in the most open fashion possible, without the need to erect communication barriers between contributors that have been granted access to the TCK and those that have not been granted such access.

I intend to closely collaborate with the Bruno Souza and the Javali project (http://www.javali.org.b) as well as SouJava (http://www.soujava.org.br) on this task.

The SouJava is the largest Java user group world-wide, and it is a member of the JCP (http://www.jcp.org). Bruno Souza is the leader of the JUGS community on Java.net (http://www.java.net), the founder of SouJava, and a famous Java evangelist.

In considering your application the Scholarship Review Board may contact you with questions for clarification or additional information.

Thank you,
The Compatibility Testing Scholarship Review Board.

Let's see if Sun's test suite is really as good as Gosling would like me to believe.

Updated: HTML-ized all the links thanks to mjw, and finished the paragraph about Sun's PR stunts.

64 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!