Older blog entries for robilad (starting at number 78)

Thanks to the tireless testers on the mailing lists, and IRC channels, a good number of issues were spotted in 1.1.6-pre1, that will be fixed with a 1.1.6-pre2 tonight. It's going very well.

People heaping rubbish on Mono and Miguel

Yay, after Microsoft showed another display of classic Microsoftean behaviour by not letting the Monos have a BOF at the PDC, the trolls erupted in joy on Slashdot. Sigh.

I really hate it when people throw mud in the general direction of Miguel and the Monos, who are doing a lot of pretty cool and useful work. Someone has to deal with the C# trap, too.

I came across this article on Barrapunto, which seems to say that Venezuela is encouraging the use of Free Software in the government over non-free alternatives. That's great news.

The odd bit in the submission is that apparently Sun Microsystems will talk to the Venezuelan government tomorrow to explain how Sun's non-free runtime can be used to write Free Software. I feel kind of sorry for Sun that they have to jump through all that because a lot of people are still unaware of the quality of, say, GNU gcj, and similar projects around GNU Classpath.

One of the points I regularly make to scared 'Java-for-life' developers, is that Free Runtimes like Kaffe OpenVM open new opportunities for them to leverage their skill set, by making it possible for them to reuse their knowledge of the language and platform in contexts in which otherwise that skill set would be useless.

For example, when a government contract mandates Free Software to be used in a solution, then either you go with a Free Runtime, or you don't get to do it at all in the Java programming language. If your code has never been tested on a free runtime, then you may have ran into the convenience trap of using non-free software in ways that make it hard to migrate your code to a free runtime, by using non-specified classes and methods, for example. Cleaning up OpenOffice.org's portability issues was not trivial and took some time to get done.

As RMS said:

"To keep your Java code safe from the Java Trap, install a free Java development environment and use it."

On a side note, the Barrapunto article probably explains the surge of Venezuelan developers on #debian-java in the last few days.

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.

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.

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.

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.

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.

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.

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).

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.