Development

GNOME Platform Stormclouds

March 24, 2004

This article was contributed by Tom Dunstan

None

Some tensions that have been building in the GNOME community for a while came out this week. Havoc Pennington wrote about the language and platform options available to open source development generally, and GNOME in particular. This sparked a large debate on PlanetGnome, among other places.

Currently the GNOME platform, meaning primarily the libraries available to GNOME developers, is written in C. There are a number of historical reasons for this: C was considered to be the most portable language around, and it allowed for very easy bindings to be written for other languages. The only real alternative when GNOME was formed was C++, which, at the time, scored lower on both of the previous measures. Also, some members of the community generally didn't like C++ as a language.

Times have changed. The Mono project was launched in August 2001 after the folks at Ximian had decided that, having gone through the pain of developing a large, multi-component application, enough was enough:

There is a point in your life when you realize that you have written enough destructors, and have spent enough time tracking down a memory leak, and you have spend enough time tracking down memory corruption, and you have spent enough time using low-level insecure functions, and you have implemented way too many linked lists.

The obvious candidate for an object oriented, statically typed, garbage collected language is Java. Unfortunately, the most widely used, certified Java Virtual Machines (JVMs) are not free software. Sun Microsystems still maintains tight control over them, and even limits the ability to freely redistribute the free-as-in-beer JVM, even without modification. Currently, to the author's knowledge, the only Linux distributions that ship with either the Sun or IBM JVMs are a few commercial enterprise distributions. While there are some free software JVMs available, their performance is generally well below that offered by the proprietary ones.

You may be wondering why languages such as Python, Perl or Ruby aren't in consideration here. Havoc's paper doesn't do much to explain why languages such as these won't be used for writing system components, because the audience that he wrote it for probably take that as a given. Dave Camp's one-liner in this blog post probably explains the thoughs of most developers on this issue: "I have a soft spot in my heart for Python (although I have a softer spot for static type checking)."

In short:

The platforms currently associated with these languages are specific to the language, the sharing of components would be difficult. Parrot, at some point in the future, may unify these languages.
These languages are not statically type checked by a compiler. To developers who have been writing primarily in C, this seems dangerously like leaving certain types of error to happen at runtime, to be discovered by users. Automated testing can address some of these issues, but a certain type of C programmer might have trouble sleeping at night after shipping a large Python application, with the expectation of receiving bug reports containing NameErrors.
At least partially due to the dynamic nature of these languages, there are limits to some of the optimizations that can be done, either at compile time or by a Just-In-Time compiler at runtime, as used by the Java and .NET platforms. Thus performance, particularly in platform libraries which need to be fast, is a concern.

Ximian saw the standardized C# language, and the standardized Common Language Infrastructure (CLI) from Microsoft as the way out: they could write a GNOME platform with all to goodies of an object oriented, statically typed, garbage collected language using and extending the existing GNOME APIs. Since the language was standardized, there were seemingly no trademark issues, and the parts of the platform that were Windows specific would be replaced with GNOME components anyway.

So Ximian founded the Mono project, and things have continued with the GNOME platform itself continuing to be coded in C, with the Mono team progressing its C# compiler, CLI runtime and class libraries at a tremendous rate.

Two things have happened recently to make some in the community start to think about the strategic direction that GNOME should take. The first is that Mono is actually approaching a 1.0 release sometime this year. The second is that the Java compiler and class library that are part of the GNU Compiler Collection (GCC), GCJ, is now considered to be fairly mature.

GCJ treats Java essentially as a subset of C++ with garbage collection and a large class library. Java source code is compiled to native code and then linked against a modified Boehm garbage collection library. Most of the standard class libraries have been implemented, with the notable exception being the windowing packages AWT and SWING. The GCJ was able to natively compile Eclipse last year, and it is considered mature enough for Red Hat to ship a GCJ compiled Tomcat Java Servlet Container in their Application Server enterprise distribution.

All of these environments will work quite well together, until GNOME makes a decision to start writing platform libraries in a managed language, for a managed platform. Whichever platform is not chosen might have a much more difficult time integrating such components. Many feel that GNOME needs to make some decision about which platform to support officially, otherwise the community will continue to be tied to C for the platform libraries indefinitely, or worse, risk forking.

There are a number of reasons given (by Havoc and others) as to why some in the GNOME community are unhappy with using Mono as the platform of choice, including:

Patent concerns over parts of .NET
General distrust of Microsoft, or strategic reluctance to adopt a Microsoft technology
Not wanting to play "catch-up", since Mono will always be behind Microsoft's implementation
Not wanting to upset IBM or particularly Sun, who have contributed a lot to GNOME over the past few years

These complaints don't necessarily impress Mono advocates, however. Software patents, some say, may well be inside Java too, either by some third party, like in the Eolas case, or by Sun itself. Sun, it is claimed, has never released a general royalty free patent license in relation to its Java technologies.

While Havoc argued that using a C#/CLR combo might "speed up" the adoption of Microsoft's technology, proponents of Mono point out that it allows a migration path away from Windows in the future, something that won't be there if the Windows world is using CLR technologies, and the free software world has no CLR.

The catching-up-with-Microsoft argument is persuasive, but Java hardly presents a better alternative. Java, under the tight control of Sun, has moved much slower than the corresponding pace of many free software projects such as GNOME, Python, or indeed, Mono. The language has evolved very slowly, with features that developers have wanted for years, such as enums and generics (templates for C++ people), only just now being added to the language, after they came out as part of C# from Microsoft, a much younger piece of software.

Sun's reluctance to support a native widget based GUI toolkit, sticking with the sometimes sluggish, alien looking SWING, left developers with no real option for developing desktop applications. There's a reason why Java is used heavily on the server, with a devoted following, but very sparingly on the desktop. To use a contrasting example, Python has evolved as a language at a much faster rate, with incremental rather than groundbreaking speed improvements over time as well. The Benevolent Dictator model is used in Python as it is in Linux, with great effect.

Keeping Sun happy seems like a very valuable goal for some in the community in light of the major contributions that Sun has made to GNOME. It's ironic, however, that the community seemingly is in this position at least partly because of Sun's refusal to let go of Java, and more ironic that one proposed solution to keep Sun happy is to use a non-Sun-licensed, non-Sun-certified Java platform which doesn't support Sun's preferred GUI APIs. While it might keep Sun happier than if GNOME adopted Mono, it would seem unlikely that that's where they'd like to be. Even if Sun were to make an open source version of their JVM and class libraries available, as advocated by IBM and others, the interaction between two competing platforms may still be awkward. It would be a great step, in any case.

Meanwhile, discussions continue, and there have been some constructive suggestions as to how to interoperate and leave the community's options as open as possible. The debate is currently civil, intelligent and constructive. There are a number of parties with big stakes involved, however, so things may yet get heated. A fragmented platform helps nobody, so there's a big incentive to work out the most inclusive solution constructively. It's a debate which will be watched closely by many.

Comments (47 posted)

System Applications

Audio Projects

FishSound 0.6.0 Released

Version 0.6.0 of FishSound is out: "libfishsound provides a simple programming interface for decoding and encoding audio data using Xiph.Org codecs (Vorbis and Speex)."

Full Story (comments: none)

vsti 0.0.3 announced

Version 0.0.3 of vsti, which allows a Windows vsti plugin to be used with JACK and alsa-seq, is out.

Full Story (comments: none)

CORBA

openMDX v1.1.0 (stable, production quality) released (SourceForge)

Version 1.1.0 of openMDX, an open source MDA (Model Driven Architecture) platform, is out. "openMDX enables software architects and developers to build and integrate software applications in a highly automated and industrialized way. openMDX supports J2SE, J2EE, and .NET."

Development

System Applications

Audio Projects

CORBA

Database Software

Networking Tools

Peer to Peer

Printing

Web Site Development

Desktop Applications

Data Visualization

Desktop Environments

Electronics

Financial Applications

Games

GUI Packages

Imaging Applications

Interoperability

Medical Applications

Office Applications

Office Suites

Science

Web Browsers

Word Processors

Miscellaneous

Languages and Tools

C++

Caml

Java

Lisp

Perl

PHP

Python

Ruby

Tcl/Tk

XML