The latest releases of
, GNU Classpath
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
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
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
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%
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
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
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.
Debian has been moving a large set of packages from contrib to main
using the above tools. More then 50
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++
to post comments)