Object Models, Google, and Star Office

According to "The Haskell School of Expression" by Paul Hudak, "Java's recent astonishing rise in popularity is rather perplexing on one hand, yet quite understandable on another. As a language, it is simple and elegant, but certainly not revolutionary." The syntax of Java is similar to C and C++ and there are semantic similarities (hence Java's not revolutionary), but this does not explain why Java was successful or what should be done next.

C++ preceded Java, but C++ objects were basically C structures with added intelligence. Objects in the C++ runtime did not retain their identity. For instance, there was no way to introspect the objects generated by the early C++ compilers such as cfront.

Document object frameworks such as Apple's OpenDoc and Microsoft's Object Linking and Embedding (OLE) required objects with a built-in identity that could be dynamically linked. Objects for these frameworks needed to be separately compiled, and loaded at runtime. Microsoft solved this problem with the Microsoft Common Object Model (COM). Apple's OpenDoc used IBM's System Object Model (SOM), which was an implementation of the Common Object Request Broker Architecture (CORBA).

Typical CORBA development had the programmer produce Interface Definition Language (IDL) bindings to a standard language such as C or C++. This required the production of several entities such as IDL stubs, IDL skeletons, etc. Introspection in CORBA required the use of a Dynamic Invocation Interface (DII) in which dynamic requests were built through a long series of C-like API calls. The CORBA code then had to be submitted to an Object Request Broker (ORB). This made OpenDoc programming a labor-intensive process. Apple tried to solve this problem by creating a "Direct-To-SOM" compiler that would take C++ class definitions and compile them into CORBA objects.

Java appeared at the perfect time and it succeeded where Direct-To-SOM failed-- it provided a simple, straightforward language for building CORBA-like objects. The objects ran in a Virtual Machine (VM), but the VM acted much like an ORB. Later, Sun published a Introspection API for Java that made CORBA DII look like a cumbersome dinosaur.

Java quickly became the perfect language for writing an OpenDoc-like component model. An early pioneer in this realization was one of my former ASU professors: Tony Faustini. Faustini taught computer language courses at Arizona State, and two of his passions were visual languages and functional programming. When Sun announced Java and Applets to the world, Faustini immediately understood the implications. Very early in the history of the language, around the time when Sun was releasing Beta Applet APIs for the upcoming Java 1.0, he did something that I wouldn't fully appreciate until much later. He apparently found the Java ClassLoader APIs, and used them to build a container that loaded a series of visual components on startup. As it went through the loading process it displayed the loaded components in a progress bar-- much like the one Photoshop used when loading plugins on startup. The result was called Visual Java (not to be confused with the commercial product that is currently being called Visual Java). Visual Java could best be described as a GUI builder using an operator-net representation of the programming language Lucid, where the operator-net entities were dynamically loaded at runtime through a ClassLoader.

Through some promotional efforts by Faustini, Visual Java soon found its way to Sun Microsystems and Java evangelist Miko Matsumura. There is an early Java-related telecast with Miko Matsumura and Sun engineer John Gage where Miko used Visual Java to first make an animated dog run forward and then run backward. I developed a MacDraw-like component for Visual Java called Fresco. Verdantium was influenced by all of this.

To make a long story short, part of Visual Java wound up in Sun's BeanBox container for Java Beans. Part of Visual Java wound up in a Sun product called Java Studio. Java Studio seems very far removed from Tony's original vision. I don't know what, if anything, happened to Fresco. In a sense Visual Java turned into Java Beans, and then Java Beans integrated, after many travails, into systems like Star Office.

Suffice it to say I found it interesting when Google today announced it was going to start bundling Star Office with its products. I think Google is starting to understand reality-- they've realized that they aren't going to do everything with web applications and AJAX. I also have doubts about whether Star Office will be a success against Microsoft Office.

Microsoft Office is the McDonalds Happy Meal of the software industry. It is a single monolithic box packed with a hamburger (Microsoft Word), french fries (Microsoft PowerPoint), a soft drink (Microsoft Excel), and a toy (Microsoft Access). Microsoft produces lots of them with enormous economies of scale, and they're all pretty much the same. Star Office is trying to be the cheaper Happy Meal, or the more agile Happy Meal, or the more international Happy Meal, or the Happy Meal that is available in more places, etc. It's hard to imagine any of Star Office's marketing slogans really working, particularly if Microsoft tried to marginalize Star by cutting the price of MS Office. It's hard to make a big monolithic box better than Microsoft. Star seems to be trying to make something a lot like MS Office, and generally seems to be trying to beat Microsoft as its own game. As a strategy, this doesn't seem to be smart.

To compete with Microsoft, Google and Sun need to address the big truth that Microsoft ignores: most people don't want Happy Meals. As Simon Phipps stated during the 2007 JavaOne conference, people want to go to a buffet table where they are free to choose what suits their tastes. That is to say, the Java community needs to develop framework technologies that can be used to leverage the best talents of the Open Source community. Different people want different application suites. Ever notice how Adobe's application suite (i.e. Photoshop, Illustrator, etc.) looks very different from Microsoft's? Observe: Adobe doesn't even provide a spreadsheet. This shows the kinds of choices that people want from their "buffet table." Some people want Photoshop instead of Microsoft Paint (or vice versa). Some people want a page layout program instead of a word processor. Some people want Gantt charts built directly into the suite, and other people would rather not have to drag all of that code through their CPUs like a boat anchor.

Unlike the typical Microsoft offerings, Java is a language that can make the buffet table work. Tony Faustini demonstrated years ago how how to write code that can put the various items on the table at runtime. It's one of the main reasons why Java has been successful as a language. Choice is a fundamental human desire, and it's a desire that Microsoft doesn't satisfy. An open framework providing choice fully utilizes the best strengths of the Java programming language. Instead of another Happy Meal called Star Office with pre-configured applications, Google and Sun should be providing the full buffet table.