DeJong Juggles Java Projects

Wednesday Nov 8th 2000 by Cameron Laird

Red Hat's Moses DeJong is pushing the envelope in the area of open-source Java projects.

Mo DeJong has more than his share of Java fun.

Moses DeJong

During the day, he's "IDE (integrated development environment) guy" for Linux market-leader Red Hat, Inc. That means he's one of the three engineers responsible for, among other things, Source-Navigator (SN). SN supports Java quite nicely, along with such other languages as C, C++, FORTRAN, Tcl, and COBOL. SN was also known in the past as the IDE for Cygnus Corporation's popular Code Fusion. Red Hat's GNUPro commercial software development suite is another to use SN for its IDE. Just a couple of weeks ago, Red Hat converted SN's license to open-source. The "buzz" around Source-Navigator is growing, reviewers are giving it favorable marks, and 'Net-wide communities have started working with its drop-in parser interface to add support for such other languages as Perl and Python.

DeJong's programming doesn't stop there, though. After hours, he is project coordinator for Tcl/Java, Jikes, and Jacks. He also helps out with the Swank, Kaffe, TkGS and GCJ projects. He insists he's not spreading himself too thin. Even Tcl/Java, a useful brew combining those two separate languages, doesn't take excessive time. One key to his productivity is his effective use of regression tests. He knows the validation suites he maintains ensure that any changes he makes truly are enhancements, not bugs waiting to be discovered: "The software just keeps improving; there are literally no regressions. The only problems people seem to run into are features that have not been implemented yet."

The Best of Two Worlds

Why bring Tcl and Java together? In the first place, says DeJong, "GUIs [graphical user interfaces] with [pure] Java are really, really bad. So bad it takes a long time to work with it to understand how bad. Swing and even AWT are easy for newbies. They're really great to get started. When you get serious, though, you find out that Java toolkits are different on all platforms, and absurdly slow to develop."

DeJong has more to give Java than just harsh words. He's made himself part of the solution. As an undergraduate student at the University of Minnesota specializing in human-computer interfaces, he realized he could complement Java's object-oriented rigor and scalability with Tcl's flexibility, portability, and encouragement to the kind of interpretive "experimental" programming important in rapid development efforts.

"As with Jikes, DeJong came to Jacks to support his Jacl habit."

Ioi Lam coded Jacl, the earliest form of Tcl/Java, while a student at Cornell University in 1997. Jacl is an implementation of Tcl in Java. By the next year, Sun Labs employed Lam, and brought out a 1.0 release which bundled Jacl and Tcl Blend. Tcl Blend allows conventional Tcl to script Java objects. DeJong was among those who began to contribute after the 1.0 release, with the result "that 1.1 was 'stable'. Then 1.2 added new features and has now replaced 1.1 as the 'stable' or 'production ready version'. [Several] different companies [already are] using it in actual products," and at least a few of these also fund further development of Tcl/Java. Among the most dramatic installations of Tcl/Java are its use to control a satellite, incorporation in both IBM's Bean Scripting Framework and Version 5.0 of Vignette's StoryServer, and a medical imaging analysis application at pharmaceutical giant Merck & Co.

One typical model for Tcl/Java deployment has business logic including connectivity and security written in Java, with Tcl as a thin GUI wrapper around high-level Java objects. Tcl, or more properly its Tk graphical extension, is a natural in this role. It's highly expressive, so that a minimal application in Tcl/Java can be as brief as

      package require java
      button .b -text "Create an object" \
	      -command {set myvar [java::new MyClass]}
This script puts up a button which, when pushed, creates an instance of MyClass.

Even more than Tcl's succinctness, though, DeJong recommends it for Java scripting because of its interactivity. Tcl's interpretive model means that a developer can type a script like the previous one directly into the Tcl shell, and immediately verify the action of new code. If a programmer already has the tiny script above, he can interactively experiment with

      .button configure -foreground red
to update the color scheme of the application. More dramatic, though, is interaction with Java objects:
      package require java
      java::import java.util.Vector
      set v [java::new Vector]
      $v addElement "String 1"
      $v addElement "String 2"
      $v addElement "String 3"
      puts "size of vector is [$v size]"
      > size of vector is 3
      set obj [$v elementAt 1]
      puts "extracted string is \"[$obj toString]\""
      > extracted string is "String 2"   

The contrast with base Java is evident. The standard

compiler that ships with Sun's software development kit (SDK) is notoriously leisurely. Applications of even moderate size can take minutes to update — and, as DeJong points out, "then the user needs to restart the entire application and get back to the point where he can test." Scripting front-ends to Java classes such as Tcl/Java make a very practical way to accelerate development schedules.

Rapid application development isn't the only reason for scripting, of course. Scripting is an excellent way to expose controlled doses of programmability to end-users. Suppose you've written a game in Java. Attach a Tcl/Java interface to it, and you give your players the opportunity to compose their own constructs in syntax as simple as

	set Sumer(speed)        17
	set Sumer(location)     (300,58)
	set Sumer(introduction) "Hi, sailor."
	set Sumer(age)          42
In such an arrangement, Tcl takes responsibility for communicating values back to the Java objects that do the real work. DeJong emphasizes, "Embedding Tcl into an application means the developer need not invent yet another configuration file format. It saves the time needed to write a custom parser as well as write up documentation for the new format."

Faster, Smaller, Able to Leap Tall Buildings

There's more to DeJong's Java life than just Better Living Through Scripting, though. One open-source alternative to JavaSoft development tools is the IBM Jikes Java compiler, for which DeJong is now Project Coordinator. Jikes compiles Java source at speeds an order of magnitude faster than

's. In a monthly column for Server/Workstation Expert, industry veteran Jim Frost writes, "Jikes is superb both in its accuracy and performance. ... [Y]ou should consider it simply because it's fast. Really fast." That speed caught DeJong's eye. "The reason I originally got interested in Jikes is because I got sick of waiting for
to get done compiling Jacl after every little change. Jacl takes 60 seconds to compile with javac, but only 3 seconds with Jikes."

DeJong has been working with Jikes since 1999. Its ChangeLog shows DeJong submitted the fourth patch after Jikes was originally open sourced. He also wrote the first autoconf based build system for Jikes, and ported Jikes to a number of systems including the Cygwin and Mingwin build environments.

Rewards of Testing

DeJong's Tcl background pays off in the domain of testing, too, where he's made many of his recent contributions to Java. Testing has long been a Tcl strength; Sybase and Oracle, for example, use millions of lines of Tcl source to implement validation suites for their database management software. He has "spearheaded a new project called Jacks. Jacks is a replacement for Sun's closed source compiler test suite."

Recall that one of DeJong's secrets in spreading himself as thinly as he apparently does is that he knows his projects are already in good shape. Between the interactivity of the development environment, and the automation of the testing suites, he gets a lot done "with just a few hours on the weekend. It makes your life so much easier [to have good tests built-in]. You don't worry about breaking things" the way developers do who operate from more subjective specifications. As he recounts, "The Tcl/Java project is a good example of how a good set of regression tests can really help with the maintenance cycle of a large piece of software. There are more than a thousand regression tests in the Tcl/Java test suite; just about every nook and cranny of the code is tested by the automated suite. This makes it very easy to maintain because if you break something, you find out right away. This type of testing is so useful that ... I had to add regression testing to the Jikes project to get anything done. Jikes was having problems; without regression testing it was not going to get any better. I had to implement a 'no new patches without regression tests' policy for Jikes. Initially, this was not well-received. Folks did not want to 'do extra work' to write tests; they just wanted to hack the code. Now they seem to have accepted the idea that every patch needs to have a test case."

The resulting Jacks is an open-source regression test suite for Java compilers which currently verifies the correctness of

, Jikes, native-code compiler GCJ, as well as kjc, the compiler Transvirtual Technologies ships with the Kaffe open source JVM.

As with Jikes, DeJong came to Jacks to support his Jacl habit. He "worked on the Kaffe JVM for quite awhile to get it working well enought to run Jacl. Once Kaffe was working, I moved on to GCJ. 'Problem was, GCJ did not really support all of the JDK 1.1 language features at the time. GCJ had its own regression testing facility, but it was not all that flexible and it only worked with GCJ. I needed a test suite that could be run with both Jikes and GCJ. After talking to David Shields, one of two original authors of Jikes, it was agreed that IBM would host the Jacks project on their server."

Red Hat itself has a half-dozen-strong Java team. Working in a different department than DeJong's IDE one, they have responsibilities for such Java projects as GCJ. GCJ supplies a Java front end to the GNU gcc compiler. "With it," explains DeJong, "you can compile Java to native code. There is no JVM, so it takes up a small amount of memory and runs real fast." His fellow Red Hat employees are already using Jacks to improve GCJ's quality, and have contributed new test cases back to the Jacks project.

Ease in Maintenance

DeJong also seems to enjoy "low-maintenance" ease in his personal life. He now lives in San Francisco and walks just a few blocks "in perfect weather — always!" to work at the Red Hat office there. It's quite a contrast with the daily commutes to Sunnyvale he endured when he first arrived in the Bay Area. While he enjoyed college, what he remembers now is that, "in Minnesota, you might walk outside and die — sometimes from cold that freezes your eyeballs, sometimes from the heat. And in San Francisco, they don't have attack mosquito squads."

The Bay Area is hospitable, too, in offering DeJong plenty of opportunities to exercise his Java talents. In late July he received a contract to improve Tcl/Java's threading capabilities, and looks forward to continuing his work with Jikes, Jacks, and other open-source projects.

Links on this story

Reach Cameron Laird through:

Mobile Site | Full Site
Copyright 2017 © QuinStreet Inc. All Rights Reserved