Development [LWN.net]

The GNU Classpath distro DevJam - Europe

September 28, 2005

This article was contributed by Mark Wielaard

The latest releases of GCJ, GNU Classpath, Kaffe and various other free software projects have made it possible for the various GNU/Linux distributions to package non-trivial applications and libraries written in the java programming language. To coordinate and advance the state of the packages, the Debian packagers suggested having a DevJam during the Oldenburg Linux Developers Meeting, which was held from September 21 to 25.. They invited various packagers from other distributions, as well as upstream developers.

The Oldenburg Linux Developers Meeting is set up in a way that makes participation as easy and inexpensive as possible. There is no entrance fee, but donations are welcome. There are several large rooms at the University of Oldenburg where people can install their computers, use the network and possibly sleep when they get tired of hacking. During the whole event a 'continuous breakfast' is provided (with lots of coffee). There are no formal presentations, but people break away from time to time in separate rooms for informal discussions. All this makes the Oldenburg meeting a really intense and productive meeting, although most participants have severe sleep deprivation at the end.

In total there were around 60 hackers present in Oldenburg, mostly working on various kernel porting efforts. Also, several Debian groups such as the Installer and Security teams were present. The GNU Classpath distro DevJam group consisted of around 14 people. Attendees included several packagers from Debian, Gentoo, Fedora, OpenEmbedded and SUSE, and some developers from the GNU Classpath, GCJ, Kaffe and Cacao projects. The participants seemed to agree on the goals (a mature Free Software packaging and development toolchain), which kept the discussions largely free of politics, and focused on technical issues.

The main subjects discussed where the completeness of the free toolchains, common packager frustrations with upstream packages written in the java programming language and how to combine and integrate GCJ ahead of time compilation with a traditional Java environment.

Completeness of the toolchain

Stuart Ballard maintains japitools, a tool that can show binary compatibility issues between libraries. On kaffe.org he maintains an overview of the binary compatibility between the free and proprietary core library implementations. GNU Classpath recently reached more then 90% api coverage when compared with the proprietary 1.4 JDK library. There is still a lot to do on the correctness, robustness and performance of the library. Some parts, such as printing, have 100% interface coverage according to japi, but no back-end implementation yet. But the recent progress has been amazing. For most of the missing parts, there are already people working on their completion. Also, a special development branch has been started to provide new 1.5 library work based on generics and other language extensions. These new language extensions are supported by GCJX, a new compiler developed by Tom Tromey. In the future, GCJX will replace the current GCJ compiler in GCC.

For the distributions a lot of the focus is not on completeness (filling that last 10%), but on making real world applications work. The interaction between the packagers and the upstream developers seems to be tight, and working out nicely. The programs that are packaged by the distributions seem to work well now, but for people wanting a full free replacement for the Java platform, a lot of work is still needed. The main worry at the moment is that there is no plan yet for a complete security audit of the full stack. This prevents distributions from packaging applet viewers and interesting applications that make use of the permission-based security framework using signed jar files.

Common packaging headaches

There were several talks about the ways Gentoo, Fedora and Debian package stuff. All of the distributions face one common problem: In the tradition Java world, there is no strong versioning system. Small updates to libraries often break source or binary compatibility. A lot of projects written in the Java language "package the world", meaning that they often just include all of the projects they depend on. Inclusions are done as binary jar blobs, probably to guard against the weak versioning of traditional jars. Luckily the JPackage project has been collecting dependency information and splitting up programs and their library dependencies in separate packages. Fedora has been trying to base all of their packages on JPackage. The other distros would also try to push any improvements (at least the versioning and dependency information) to JPackage so they can easily be shared between the various packagers.

GCJ and ahead of time compilation

With GCJ 4 it is easy to mix and map traditional java byte code with ahead of time compiled shared libraries. Ahead of time compilation reduces startup time and can reduce resource usage since several processes can use the same shared library. One of the tools for this is gcj-dbtool, written by Andrew Haley. gcj-dbtool allows for setting up a system-wide database mapping of classes to pre-compiled shared objects. Using the MD5 sum of a class in this database, a program that loads a class or jar file will automatically map in the correct ahead of time compiled shared library without needing to interpret or just in time compile the byte code. This process can be made almost completely transparent to the program, developer and packager using aot-compile. This is a new tool written by Gary Benson for automagically finding, extracting and pre-compiling all classes found in a package with gcj, then storing them in the correct gcj-dbtool database. Together with gcj-java-compat, by Thomas Fitzsimmons, it provides a traditional looking Java platform that automatically uses ahead of time compiled code whenever possible without the user or developer having to setup anything special. The aot-compile tool is currently somewhat RPM specific, but will be made generic enough so that it can be adopted by the other packaging systems.

Future developments

Debian has been moving a large set of packages from contrib to main using the above tools. More then 50 packages that used to depend on a proprietary Java toolchain can now be freely used. For some packages, like Eclipse, gcj ahead of time compilation is being added. Fedora has rolled out Fedora Core 4, which included some native-compiled applications like Eclipse and the OpenOffice.org 2 plugins written in Java. All of those were precompiled with gcj. For Fedora Core 5, they want to add some major applications like the Jonas application server. For a list of potential packages that might pop up in future releases of the various distributions look at the free section of jpackage.org. The meeting seems to have been such a success that there are already plans for a DevJam++ meeting.

Comments (1 posted)

System Applications

Clusters and Grids

Release 2.0.2 of Linux-HA is now available

Release 2.0.2 of Linux-HA, the Linux High Availability project, has been announced. "This release has been restricted to a small number of important bug fixes."

Full Story (comments: none)

Database Software

The first MySQL 5.0 release candidate

The first release candidate for MySQL 5.0 is out. The announcement (click below) calls 5.0 "certainly the most important release in MySQL's history." Changes include many new SQL standard features (views, triggers, and stored procedures, for example), some new storage engines, and more.

Full Story (comments: none)

PostgreSQL Weekly News

The September 25, 2005 edition of the PostgreSQL Weekly News is online with the latest PostgreSQL database articles.

Full Story (comments: none)

Proboscis 0.1 Released

Proboscis version 0.1 has been released. "This is the first release announcement for Proboscis[1], the PQueue based Green Trunk implementation. It is a PostgreSQL driver/interface for Python. Another one? Well, yes and no. Proboscis is not libpq based, nor does it primarily produce a DB-API 2.0 interface(0.2 may include a layer for DB-API 2.0 users)."