Older blog entries for robilad (starting at number 76)

Kaffe on Cygwin

After a few days of wrestling with bizarre library name lookup issues, and Cygwin's assembler's lack of appreciation for nice x86 assembler PIC code function declarations, I've managed to get Kaffe building and running largely fine under Cygwin, so that now people can hack on Kaffe on Windows, as well.

That was actually an ocassionally requested feature, in particular in the post-Harmony-announcement rush of good will and volunteers to try it out and see how far along that whole free runtime thing is. And as a lot of people are stuck using a popular, non-free platform, but apparently nevertheless want to help out on free runtimes, ...

The upcoming 1.1.6 will be able to run on Cygwin. See the docs for details.

I'll go back now to preparing the release, and merging in the remaining patches.

10 Sep 2005 (updated 11 Sep 2005 at 12:56 UTC) »
Another Modest Proposal: Ending license discussions quickly

It was pointed out to me that my last week's modest proposal was helpful, but may still leave too much room for normal, non-lawyer people to waste their time decyphering pseudo-clever, condensed lawyerese.

Again, it's simple: Just add a variant of Godwin's law to the OSI definition.

12. Gowdin's law: If, during the discussion of the list on he OSI lists, the license steward needs to invoke or refer to the opinion of a lawyer to convince the public that the license is indeed open source, the license automatically fails this variant of Godwin's law, and is no longer considered open source.

A modest proposal: Ending License Proliferation Quickly

It's simple. Just add the following rule to the OSI definition:

11. A license must not be longer than 200 words.

A low limit penalises long excursions into incomprehensible lawyerese gibberish, while forcing the license submitters to concentrate on the important stuff: granting other people broad freedoms to use, modify, study and distribute works so that people don't have to ask lawyers, or go to courts to figure out their rights.

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.

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