February 27, 2021
Hot Topics:

Kaffe -- one for all

  • By Peter C. Mehlitz
  • Send Email »
  • More Articles »

Memory management

Kaffe's heap management still has a non-incremental mark&sweep garbage collector. While the Desktop Edition recently introduced precise garbage collection (for reference fields), this is not yet the big overhaul, which is due during the second half of the year. Its main goals will be faster allocations and a much more incremental collection. This will also involve the introduction of write barriers.

Thread systems

The most heavily used thread system of Kaffe is the jthreads module. It is a sophisticated, portable user-thread model that is specifically tailored to the needs of Java and supports asynchronous I/O (by means of SIGIO). There are several different kernel-thread implementations in the Custom Edition and a not-yet-finished pthreads system in the Desktop Edition.

The AWT does not require any public or proprietary native toolkit.

Of course, user threads are no choice for multiprocessor systems, and are less efficient for heavy I/O (i.e., for servers). But they come with a silver lining for all other applications -- lock efficiency. The lock interface (e.g., for synchronized blocks and explicit waits) is another hot spot of current Kaffe development. With large, multi-threaded libraries like Swing, it will become even more important.

Graphics support (AWT)

With respect to 1.1 functionality, the AWT implementations are complete (and run Swing smoothly). All widgets (like Buttons, Lists, and TextAreas) are implemented in Java (as so-called lightweights).

There are some remaining minor compatibility issues, which are mainly caused by the different behavior of native widgets and lightweights (e.g., Panel vs. Container derived Components), but many of these problems are platform-specific and can be seen on other AWT implementations, too (which indicates a need to improve the AWT specification).

The main conceptual difference to look for when comparing Kaffe to other AWT implementations is the lack of peer functionality. The reason behind this is very simple: with the current native interface (implemented in Toolkit), the pure lightweight AWT shares the same Java classes for all supported platforms (just the native library "backend" needs to be exchanged). Peer implementations would just increase the number of objects/classes, or would even end up in hidden, platform-specific classes (in addition to platform-specific native libraries). This assumes a homogenous AWT (all objects are served by the same native library), but heterogeneous implementations are currently rather exotic (e.g., rendering windows on different displays from within the same Java process). Moreover, a native widget-based AWT is already in the works (there even is a GTK-based prototype), and it shows that the Peer-less design can be used there, too.

Otherwise, the lightweight approach often outperforms native toolkit-based implementations. It also uses fewer resources, eases ports, and is much better suited for adaptation to specific look-and-feel needs (with a fraction of the overhead involved in comparable Swing-based solutions).

The Desktop Edition AWT is based on plain Xlib and does not require any public or proprietary native toolkit library, like GTK or Motif.

The standalone AWT of the Custom Edition, which works on top of simple graphics libraries (providing only primitives like DrawLine, etc.), has been further factorized and can be easily adapted to new libraries (typically, less than 2000 lines of code). This turns it into a preferred choice for small systems with non-standard display.

Human resources

Who are the driving forces behind Kaffe? People, not companies or organizations. These people represent very typical groups, having their own interests in Kaffe.

Tim Wilkinson is the first one to mention. He started the whole project in January 1996. Bored by a dinosaur project he had to work on in Stockholm, Sweden, he wrote and released the first version of Kaffe in less than a month. The name Kaffe is a reminiscence of that era (it's Swedish for coffee). Tim founded Transvirtual in November 1997 and continues to do most of the core JVM work.

Ongoing performance improvements will bring Kaffe to the same level as proprietary, state-of-the-art JVMs.

Tim represents the group that is fully committed to Kaffe, building a business around it.

Godmar Back gets the credit for keeping the Desktop Edition and the community of developers that work on the project together. Besides maintaining the www.kaffe.org Web site, he does quite a bit of development and integration work in the JVM area (namely, the thread systems). Godmar is also involved in the KaffeOS project.

Alexandre Oliva uses Kaffe as the basis for his Guaraná research project. He improved the build process, by means of the Libtool package.

Both Godmar and Alexandre are from the academic research community, where Kaffe has always been popular, because of its availability of sources (and the right to modify them).

Archie Cobbs of Whistle Inc. did a lot of work on the libraries and related JVM parts. He joined the team because Whistle considers Kaffe to be useful for their products, which shows that there can be commercial prospects in the GPLed Desktop Edition, too.

Of course, there are many more. Daniel Veillard of W3, managing the mailing lists. Eduard Parmelan, constantly improving the libraries. Kiyo Inaba, sorting out various porting problems. There are simply too many for this article, who would deserve to be mentioned. Browse the mailing list archive, and you will find all of them. This is less surprising when you take into account the fact that Kaffe is included in every Open Source Linux distribution and has been around for four years.

Step into the future

This leaves us with the question of Kaffe's future. Two facts seem to be obvious: (1) Kaffe already has a significant level of maturity, and (2) there already is enough "critical mass" in its developer community to keep it vivid, even when facing new Open Source Java projects like Japhar, ElectricalFire or Classpath. With its Custom Edition, Kaffe has also found a commercial niche, not threatened by one of the larger players (who can't provide Kaffe's portability and scalability, even with quite a bit more manpower).

Moreover, the ongoing performance improvements will bring Kaffe to the same level as proprietary, state-of-the-art JITed JVMs. With the expected tremendous growth of the embedded systems market and the ever-increasing role of Java as a general application platform, the future is wide open. And Kaffe already has its share of success in that game.

About the author

Peter Mehlitz is co-founder of Transvirtual Technologies. He designed and implemented the AWT libraries of Kaffe. Prior to that, he worked as a technical lead for BISS GmbH, developing systems like the BSA C++-framework, the CThrough development environment, and the BISS-AWT Java libraries. Peter has about 20 years of experience in software development, using about a dozen different programming languages, with a strong focus on design issues and large, object-oriented frameworks (written in C++, Smalltalk, and Java). He holds an M.S. in aerospace engineering from the university of the German armed forces, Munich.

Page 2 of 2

This article was originally published on May 5, 1999

Enterprise Development Update

Don't miss an article. Subscribe to our newsletter below.

Thanks for your registration, follow us on our social networks to keep up-to-date