Volume Number: 15 (1999)
Issue Number: 5
Column Tag: From The Factory Floor

Jens Alfke, AWT Engineer

by Jens Alfke and Dave Mark, ©1999 by Metrowerks, Inc., all rights reserved

This month's Factory Floor interview brings us back inside Apple for a visit with Jens Alfke, world famous creator of the Stickies desk accessory. Of particular interest this month is Jens' work reimplementing the AWT Jens' work re-implementing the AWT (Abstract Window Toolkit), the core Java user-interface framework, in the latest release of Apple's Java runtime, MRJ.

Jens Alfke, a Java Toolkit Engineer at Apple, led the effort to re-implement the AWT library in version 2.1 of Apple's Java runtime, MRJ. He has previously worked on OpenDoc and AppleScript, but is probably best known as the author of the popular Stickies desk accessory. After the demise of OpenDoc he spent a year working at a startup company and at the Java division of Sun, just to get a feel for how awkward using Windows NT on a daily basis really is. His main extracurricular technical interest is designing protocols and user interfaces for futuristic e-mail and discussion systems. In his spare time Jens plays Lego and Skwish with his two young children, saves the land of Hyrule from the evil Ganondorf with his Nintendo64, and DJs drum'n'bass and ambient music at friends' houses.

Dave: Given that Apple is a Sun Java licensee, how do you go about implementing your own version of the AWT?

Jens: There are two halves to any AWT implementation. One half, the one developers know about, consists of the public classes in the java.awt package. These define the API and much of the behavior, but they are of course incomplete because they're cross-platform and can't talk to the platform's GUI to really make anything happen onscreen.

The other half, then, is a set of platform-specific Java classes that implement the real behaviors such as creating windows, managing controls and handling events. The way the two halves connect is that some of the public classes (like Graphics) are abstract and have to be subclassed by the platform-specific AWT code, and other public classes use abstract "peer" interfaces to communicate with a set of corresponding private classes. Our AWT consists of both these concrete subclasses and implementations of the peer interfaces.

In most Java implementations the platform-specific side of the AWT is mostly written in native code - most of the private classes consists of native methods that are implemented in C or C++. But in our new AWT implementation in MRJ 2.1 we used Java wherever possible, using our JDirect feature to call the Toolbox directly and only resorting to C++ for some low level glue or for really heavily optimized graphics code. So for instance, all our code that manages controls consists of Java classes that directly call the Control Manager just as a normal Mac application would. Doing it in Java really simplified our development and resulted in cleaner code.

Dave: What was involved in rewriting the AWT?

Jens: The previous AWT implementation descended from code written at Javasoft for their old "MacJDK". It was pretty poor quality code and had to be fixed up a lot for MRJ 1.0; and it was then further hacked and extended in MRJ 1.5 and MRJ 2.0. It was clearly a codebase that needed to be thrown away and rewritten. It was also very inefficient in its graphics code, and it draw controls itself, which made it not theme-savvy.

So last May we took a deep breath and started writing a new codebase from scratch. Well, nearly from scratch - we copied over a few pieces of the old AWT (such as menu handling) and grabbed an experimental C++ library I'd written for OpenDoc that did hierarchical view management. But about 95% of the code is new.

By the time MRJ 2.1ea2 was released in August, we had an alpha-quality AWT that developers were pretty happy with. We actually kept the old AWT hidden inside ea2, with a secret switch to enable it, in case of emergency if developers ran into insurmountable problems trying to run their apps with the new AWT. But we never had to tell anyone how to enable it!

After that it was mostly a series of bug fixes and compatibility tweaks to make sure we matched every semi- or un-documented behavior of the JDK. There's no real specification for the detailed behavior of the AWT, so we had to rely on our own testing and lots of 3rd party bug reports to discover all the subtle JDK behaviors that people's code relies on, and implement them the same way in MRJ.

I started the task and did a lot of the core stuff, but the whole AWT team made it happen - Shehryar Lasi, Steve McGrath, Lee Ann Rucker, Pete Steinauer, Steve Zellers. Nick Kledzik and Nick Thompson helped out with specific features too.

Dave: These days, what are the pieces that make up the AWT?

Jens: At the lowest level there's a layer that plugs into the JManager library - that's how we receive events from the host application, and request things like windows and menus from it. Then the view system manages the hierarchy of components and containers and their clipping. There's a bunch of really complex event handling logic that maps the Mac event model into the Java event model.

Then there is our Toolkit class that acts as a factory for peers, and the component peer implementations themselves - these are where the public Java classes like Component and Button tell us what to do to make things happen onscreen. Many of these peers talk to the Control Manager, and our text peers talk to a new text editing library called Textension. Menu classes have peers too.

We have a subclass of Graphics and two subclasses of Image that implement all the abstract methods of drawing and image management. And there's a lot of miscellany for dealing with cursors, fonts and so on.

Dave: Anyone who runs the CaffeineMark benchmark knows that MRJ has made some giant strides recently. What has been done to the AWT to contribute to this?

Jens: The new AWT gives most Java components their own GrafPorts, and ensures that we never draw into the host app's window's GrafPorts. This means we don't have to spend as much time setting up and tearing down GrafPort state like clipRgns and colors, since there aren't as many different things trying to use the same GrafPorts. The new code is very lazy (in a good way!) about setting up state only when it's necessary and preserving state as long as possible.

On top of that is the graphics pipeline, which speeds up primitive drawing operations such as lines and text. These calls are written into a big array in opcode/operand style. When the array fills up, or when a split second has gone by, we make a single call to a native function that parses the opcodes and does all the QuickDraw calls. This gets around the "mixed-mode" overhead of frequent transitions between Java and native code and lets us further optimize the way we set up GrafPorts. Our raw drawing performance is now within a few percentage points of the limit of what QuickDraw can achieve.

And of course I have to give thanks to the Symantec JIT (Just-In-Time compiler) and kelly jacklin's work in integrating it - I don't think that implementing the AWT mostly in Java would have worked nearly as well without the pure speed of the new JIT.

Dave: What else changed from AWT 2.0 to 2.1?

Jens: We now use native controls - that is, we use the Control Manager for things like buttons and checkboxes. We used to draw our controls by hand; they looked awful in MRJ 1.X, looked more like real controls in MRJ 2.0, but they still weren't theme-savvy. Now with MRJ 2.1, if you change your system's appearance by installing Appearance Manager themes or Kaleidoscope schemes, the controls in Java apps will fit in. With OS 8.5 installed we also support proportional scrollbar thumbs, live scrolling and UI sound effects - in all themes.

We now use some very fast QuickTime blitters to display images.

We use a new text editing library called Textension, which will be part of the upcoming ATSUI (Apple Type Solution For Unicode Imaging.) It's a very powerful text editor, but the Java text component APIs are pretty limited, so the major benefit we get out of it is that we're no longer limited to 32k of text.

Our FileDialog implementation now uses Navigation Services if it's available.

And in general, our stability has improved, and we're a lot better at conformance with other Java implementations, so a lot of real live Java apps that were developed and tested on other platforms now run much better in MRJ.

Dave: : Tell me about Java support for Mac OS X?

Jens: OS X Server, which recently shipped, includes its own Java, which is unrelated to MRJ. The virtual machine is a straightforward port of Sun's Solaris JDK, since OS X is BSD Unix compatible. The AWT is implemented using the "Yellow Box" or OpenStep framework.

It works well, but it doesn't include the Symantec JIT, and the AWT isn't as highly tuned as the one in MRJ 2.1, so it's not as fast as MRJ 2.1 in general. It may be faster for server type applications, though, since OS X has better I/O throughput than Mac OS 8.

For the final OS X, scheduled for late this year, we'll take a hybrid approach. The virtual machine itself will be based on the current one in OS X Server. This is great, since as I said it's a straightforward port of Sun's code and therefore there will be very few compatibility issues to worry about. We'll integrate the Symantec JIT.

The AWT will be based on the one in MRJ 2.1. Actually, we're "Carbonizing" our AWT, just as a developer would Carbonize their native app, so it will run on either OS X or OS 8. That way we can keep the same codebase for both operating systems and have the same functionality on both. The Carbon strategy makes just as much sense for us as it does for, say, Adobe!

We think this will be a really great product. The Unix-based virtual machine will get us around the limitations of the current OS's threading, memory management and I/O, while the Carbon-based AWT will continue to provide very Mac-like appearance and functionality.