This note’s for you

.. I’m working on a couple of things in parallel:

On one front I’m trying to provide a replacement for the graphics rasterizer in OpenJDK. As far as I can see to this point, the rasterizer I implemented for GNU Classpath should be fine for a start. I offered this to OpenJDK, but there seem to be a couple of legal and organizational hurdles to take. I am discussing how to best solve these issues and move forward with the code. It looks like going through the copyright grantback procedure with the FSF for the code in question is hard to avoid. In the meantime, Jim from the Java2D team has factored out a preliminary interface for the rasterizer, and Mark Reinhold offered to provide early read-only VCS access to the Java2D workspace. Thanks!

Then I am working on integrating the OpenJDK class library into the JamaicaVM. It turned out that the package-after-package approach is much more painful than expected, due to massivly intertwined dependencies. I even spotted a couple of places where private methods in ‘alien’ packages are called via reflection (urgs). I wonder how that went through QA, and I wonder what happens when one such method changes… Anyway, with the release of IcedTea I switched to importing all classes at once, with the help of the IcedTea classes this was surprisingly painless. Now I’m working with my collegues to get the native things done. So far we found that they even have some kind of VM/native interface in place, at least for the classes that I looked at so far. Basically, platform dependend syscalls are abstracted out as JVM_* functions. I hope to get a HelloWorld running this week.

Related to the OpenJDK/JamaicaVM porting work, I am working to get the Classpath GTK peers, and the other AWT backends in Jamaica to work with the JDK. The biggest problem here seem to be the differences in Image and Font handling, which are abstracted out in a backend-independent way in GNU Classpath, but seem to be implemented rather monolithically in OpenJDK. Dunno how to solve that. It might be possible to use the OpenJDK implementations when the encumbered pieces in the font and graphics rasterizer are solved. So far I think we have to go with a bunch of GNU Classpath classes in java.awt.***.

It seems to be good news day today, IcedTea is going public. This has a couple of interesting consequences:

• It allows to build and bootstrap OpenJDK without any binary plugs. The disadvantage here is that the encumbered functionality isn’t available right now.
• Distros that value freedom like Fedora and Debian can package this and include it in their main repositories.
• People from outside the OpenJDK (especially but not limited to GNU Classpath) can play with the OpenJDK code without the need to go through the contribution process (which seems to be in a flux now and for some time beeing I guess).
• The encumbered ‘interface’ is separated out nicely as stubs. This is much easier than going through the OpenJDK sources to find the necessary classes and methods. These ‘only’ have to be implemented then. I will have a look at how my rasterizer fits in there.
• It kicks Sun (and the community) in the buttock to get their contribution process clean and lean, and to get the encumbrances fixed, otherwise they risk the community going to IcedTea instead of OpenJDK.

I think I’ll really revive that old project of mine now. I cleaned up the CVS a little for a start. And in order to show that I am serious I also fixed one of the three reported bugs.

The short term goal would be of course to close the other two bugs too and then push out a release. This shouldn’t be too hard really, except that I have no idea yet, how to open any kind of file on MaxOSX. I’d need something like gnome-open for Gnome or kfmclient exec for KDE, which simply takes a file path as argument and tries to open that file according to its mime type. Help from MacOSX experts is greatly appreciated here.

The long term goals/ideas for (which would make up a 2.0 release when I come this far) are:

• Replace the RTF stuff with HTML internally. This would greatly ease the usage of the right hand side description panes and allow to insert hyperlinks to 1. other nodes in the tree, 2. any web page or file system resource (yay!).
• Re-integrate the hypertree support for much nicer navigation inside the tree view. However this is a patented technology and would be optional and not hard linked as long as that patent hasn’t expired.
• Support printing.
• Improve import/export functionality.

This is going to be a pseudo rant. So read on or not…
(more…)

The last couple of days I have desparately tried to use NetBeans for some of my work instead of Eclipse. Read on for a skimmy comparison (or rather, a list of issues that I found with NetBeans)…
(more…)

Ok I think I’ve got it now. Here’s how I did it:

1. Install Bogofilter
2. Remove the spamassassin plugin. Disabling it is not enough, I had to dorm /usr/lib/evolution/2.8/plugins/org-gnome-sa-junk-plugin.eplugI noticed this problem when running evolution from command line, which spits out a warning that one plugin couldn’t be loaded because another one is already installed. Pretty stupid bug if you ask me.
3. Feed bogofilter with some spam (that’s the easy part, simply mark at least one incoming spam mail as such) and some ham (that’s a little tricky because all mail initially comes into the inbox. I did this to learn one random mail from my inbox:cd .evolution/mail/imap/roman@kennke.org/folders/INBOX
   bogofilter -n 9999.

Now it seems to at least do something. Lets see how it works out when the filter is trained better.

Today I’ve been working a little more on Jamaica’s WindML implementation for BufferedImage, which is shaping up nicely now. ARGB8888 is now quite fast (not accelerated by the hardware though) as is ARGB1555 (this one’s hardware supported but not really accelerated as it’s represented in the generic memory pool). The missing pieces are RGB565 images and VolatileImage for the real accelerated stuff in video memory. Somehow I enjoy doing close-to-the-hardware stuff.

Dear lazyweb. I am wondering how the spam filtering in evolution is supposed to work, as for me, it doesn’t. I have patiently marked all incoming spam as spam and non-spam as non-spam (which was easy, as never any single email got sorted out as spam so far). I am using two IMAP mailboxes. Does the spam filter not work on those? After all I think it would have to download all the mail body in order to filter it. But then again, I think evolution should tell me so, and not let me sort all my emails for weeks without any filtering. So, does spam filtering in evolution only work on POP or local boxes? Do I have to tweak some configuration option? Do I need any additional software besides spamassassin?

On a completely different note, I was slightly wrong with my last picture of the inner workings of BufferedImage. Dmitri from Sun’s Java2D team was so kind to explain in detail how this is supposed to work and how it works in their implementation (thanks Dmitri). Having two buffers and syncing them is supposedly not the way to go. My intention with this has been that we would have only one rendering engine doing all the rendering, but this is probably wishful thinking. If I understood Dmitri correctly there are (at least) 3 renderers for Java2D in Sun’s impl, one HW accelerated for Windows and VolatileImages, and 2 software renderers for BufferedImages (one generic and one with specialized impls for the known formats).

For Classpath this means that we should drop the two buffer scheme, let Cairo do what it can do (basically RGB and ARGB) and do the rendering on the remaining formats through the Java based renderer (which is suprisingly effective after my tweaking, but of course by far not as effective as a C based renderer could be, because in C I can access memory much faster without bounds checking etc). Hopefully soon we are able to utilize Sun’s implementations for the BufferedImage. Can’t wait to dig into this

Today I found this gem on /. (must be the needle in the hay). This is simply ridiculous: Having an XML tag (or attribute, whatever) named autoSpaceLikeWord95 with the explanation: To faithfully replicate this behavior, applications must imitate the behavior of that application, which involves many possible behaviors and cannot be faithfully placed into narrative for this Office Open XML Standard. If applications wish to match this behavior, they must utilize and duplicate the output of those applications. Eh what? This is about to go into some kind of ‘official standard’? WTF?
And that is not the only one. This (6000 pages) spec seems to be full of it. I agree with the above article: This is not a specification; this is a DNA sequence.

*Laughing my ass off*. Oh wait, this is actually not funny. :-/

When you are so worried about the Freedom of software and collaboration, why don’t you start with your own project and do not include proprietary drivers in Ubuntu? While it might be more short term fun for the blink addicted, it is a clear slap in the face for the Free Software community. This is no use for any FOSS project, not for the free driver developers, not for any other distro and (most importantly for you) not for Ubuntu.

• Free driver developers don’t benefit from that move because they will not get that much bug reports from Ubuntu users.
• Other distros / projects don’t benefit from that move because the development of the closed drivers is, well, closed.
• Ubuntu itself risks to loose quite a bit of its momentum when FOSS developers and advocates get pissed off by that move. It’s like if you tricked them to use and advocate Ubuntu because you made a big show about beeing all Free and all that, and then you slap ‘em in the face by including binary-only stuff on the install CD.

GNU Classpath is quite a good example that shows why it is important to stand for Freedom. Would Red Hat/Fedora have gone the Sun-Java route in the past and not invested in the GNU Classpath project, we most likely wouldn’t see Sun GPLing Java now.

When one of the most important distros includes binary drivers, then it is much less incentive for ATI and the likes to release their drivers/specs under free terms. OTOH, when such an important distro takes a stand for Freedom, this is much more likely to put pressure on the vendors.

So, please do support the free driver developers and don’t shoot them in the back.

Update: In order to pull a reference to my last post, and because it fits so nicely, let me rephrase Let’s Impeach the President:

Let’s impeach the president for hijacking our religion and using it to get elected. FLIP: Our work on Ubuntu is driven by a philosophy on software freedom that we hope will spread and bring the benefits of software technology to all parts of the globe. FLOP: All of the application software installed by default is Free Software. In addition, we install some hardware drivers that are available only in binary format

Update 2: Planet Ubuntu is now also featuring some articles from Ubuntu developers getting concerned. That makes me hope that Canonical thinks again.

‘Right there over the hill you see the first rays of a New Rising Sun’ was what Jimi Hendrix said at the final Woodstock morning, after 3 days of rain and a couple of years of the hippie era, which at this time was riddled by drugs and apathy. He probably envisioned a new era starting up, which unfortunately didn’t really happen, except if you count John Lennon’s activism. And no I don’t see any (often cited) parallels between the hippie movement and the Free Software movement, despite both having ‘Freedom’ right on their forehead and often longish hair and beards
So Sun is going to release Java under the GPL (+ex). That’s really awesome great news! That is really a surprising and bold move by Sun and I think this is the best thing that they could do to get their Java ship running well again. Not only is this a good thing for the Free Software community, which has long wined about the Java situation, I think this is also good for Sun. Now they can really embrace on Write Once Run Everywhere. Sun themselves so far were not 100% able to deliver their runtime for every kind of platform. Now the community can help out and get Java running on whatever platform you could think of. Just look at Kaffe (aka the NetBSD of the Java runtimes). Sun wouldn’t care about most of the supported platforms of Kaffe. And rightly so. Only now is the community that cares about these platforms able to lend a hand in porting Java over.

So what about the future of GNU Classpath? I can only speculate now, the chestnuts are too hot right now (and probably get even hotter), but let’s try anyway. And, this is from my developer POV only. The fact is that now there is really no hard need for the GNU Classpath project anymore. But I want to raise two aspects here: 1. Many projects are built around GNU Classpath right now. It won’t be exactly easy and trivial to port them over to Sun’s libraries. Surely, it can and will be done, but for the time beeing GNU Classpath is still needed. (And could IMO provide a migration path). 2. The development environment of GNU Classpath is much more flexible right now. This spirit of hack - test - commit is part of what makes GNU Classpath attractive for developers, including me. I don’t think that this will be possible with Sun’s code, and rightly so. So, what I really would like to see would be a development process on Sun’s (and our) side that would allow hackers to hack on whatever project they like, and let one project include code from the other. Now, that is not an easy task and might not be possible at all. But let’s dream for a moment (man, those endorphines seem to be high today ). So, I think both codebases will peacefully coexist for a while, and most likely converge too quite a great degree. If at a later point they merge into one or if they will continue to coexist, time will tell.

For the Harmony people, I feel a little sorry right now. They won’t be able to easily include Sun’s code for some more time. But, the GPLv3 is there at the horizon, and hopefully this will be even more incentive to get the GPL vs APL issues worked out.

Last but not least, THANK YOU SUN! Now we’re sitting in the same boat. Lets go together and bring that ship to new glory!