Oak and WebRunner

By Richard Morin, Technical Editor
SunExpert Magazine

February 1995. Vol. 6, No.2

Last month, I discussed the GROW project, which hopes to build an extensible superset of Mosaic (and more). GROW promises to allow its users to download code at need, supporting arbitrary communications and user-interface protocols, all without sacrificing either portability or system security. GROW is based on Scheme, but the language isn't really a key issue.

This month, I'll cover a similar approach to the same end. The Oak language was initially developed by James Gosling of Sun Microsystems. Later versions of the compiler and the WebRunner program itself were developed by a team of Sun engineers.

Gosling is well-known for his design and programming skills. He developed a commercial version of Emacs, now sold by UniPress, and designed and developed the innovative, if ill-fated, NeWS software.

Oak is a programming language and environment that was designed to solve a number of problems in modern programming practice. To ease the problem of learning yet another programming language, Oak's designers started with C syntax and semantics, adding carefully selected features from C++. To reduce complexity (and consequent programming errors), they left out quite a few things.

In an as yet unpublished paper on Oak, Gosling writes, "Oak omits many rarely used, poorly understood, confusing features of C++ that in our experience bring more grief than benefit. This primarily consists of operator overloading (although it does have method overloading), multiple inheritance and extensive automatic coercions . . ."

Gosling and his colleagues then added some handy features: automatic garbage collection, dynamic method resolution, dynamic (runtime) error checking, assorted security features, multiple threads of execution, portable interfaces (e.g., an abstract Window class) and support for distributed objects. Finally, they figured out how to make all these components perform well as an architecture-neutral, interpreted system.

Oak's designers dislike the fact that C++ classes are completely defined at compile time. New or modified C++ libraries cannot generally be added at a later date without recompilation of the entire system. Obviously, this greatly reduces modularity and overall flexibility.

Looking over James' paper on Oak and WebRunner, I see many things to like about Oak, and very few to dislike. The basic ideas look like things that C++ could really use: simplicity, safety and better support for programming constructs. About the only thing I might add is a prototyping editor that would allow me to write my usual lazy code, then fill in for me with reasonable declarations.

WebRunner

With Oak as a base, you can build all sorts of nifty distributed applications. In particular, you can build a replacement for Mosaic, with very similar goals to those proposed for GROW.

"WebRunner is a system built on top of Oak that brings to the concept of hypertext access to the Internet pioneered by Mosaic a new dimension of dynamic behavior," Gosling says in his paper. "It brings the Net to life. Oak allows code to be dynamically linked into a running application in a manner that is independent of the CPU architecture of the system it is running on, and providing strong guarantees about the security of the system - eliminating the possibility of viruses."

Because WebRunner is built on top of Oak, and because the protocol and data handlers can be imported at runtime, the actual WebRunner program is very small. It is inordinately powerful, however, because it can (in principle) invisibly and securely leverage off of an Internet full of support code.

Although I am torn on the issue, my personal taste for algebraic languages disposes me strongly in favor of Oak/WebRunner, rather than GROW.

The only unmatched capability that GROW offers is the ability for programs to generate data structures and then execute them, without any intervening compile. This is a very powerful capability, but I'm not sure how often it is really needed.

Further, in many cases, a function (excuse me, method :-) can be generated, compiled and linked in at a reasonable cost in execution and wall clock time. This won't always yield the same capabilities as the Scheme approach, but again, I'm not sure how many times the difference will be critical.

Project Status

The Oak/WebRunner code is going into Alpha test at this writing. Gosling expects it to be available on the Internet by the time this column reaches print. (Contact webrunner@sun.com for project status, etc.) Thus, folks will have quite a while to play with Oak/WebRunner before the GROW project gets its code into circulation.

In a way, this is a very good thing. The GROW project will have an existence proof (and a testable implementation) of many of its ideas. It also gets an opportunity to figure out ways for GROW to improve upon Oak/WebRunner's abilities.

Alternatively, the GROW project might decide to link up with the Oak/WebRunner effort, leaving a Scheme interface as a side-effort. Part of this decision will be based on the exact restrictions under which Oak/WebRunner is released. No matter what happens, however, I think we will all benefit. Good ideas and implementations tend to breed others, and we can use all we can get.

I am personally grateful to James Gosling for his cooperation in letting me quote from his paper, and for demonstrating the Alpha version of Oak/WebRunner. All of this pales, of course, in comparison to his (and Sun's) efforts in creating and releasing this nifty piece of software.

Richard Morin operates Prime Time Freeware (ptf@cfcl.com), which publishes mixed-media (book/CDROM) freeware collections. He also consults and writes on UNIX-related topics. He may be reached at:

Copyright 1995