Will Java Kill Smalltalk?

The ANSI X3H7 Object Information Management Technical Committee has been evaluating the relative merits of object models since its inception in 1991. As Secretary of that committee, I participate in an ongoing analysis of the advantages and disadvantages of the object models implicit in the various object oriented languages.¹ After working on object database systems built in C++ from 1986-93, I worked for a Smalltalk company supporting development of MIS business applications during 1993-96. The relative merits of Smalltalk versus C++ were brought into stark relief during this period as the Enfin Smalltalk development team launched new products for design, assembly, and reuse of business objects.

In 1994, Micro Focus announced an object-oriented COBOL product. We needed to integrate Smalltalk with both C++ and COBOL applications, so I took a close look at OO COBOL. The ANSI X3H7 Technical Committee maintains a liaison with X3J4, the OO COBOL Technical Committee and Micro Focus has been a driving force on building consensus for the emerging OO COBOL standard. It was interesting to compare the anticipated merits of OO COBOL with Smalltalk and C++ in a recent article published in Object Magazine.²

More recently, my findings as Chair of the VMARK's Software's internet strategy committee were reported at Object World and the New York, Atlanta, and Massachusetts Smalltalk User Groups.^3,4 The Internet, and particularly the World Wide Web and Java are having a major impact on software product development and product positioning. At User Group meetings, at major conferences, and in the Usenet Newsgroups, Smalltalkers everywhere are asking, "Will Java kill Smalltalk?"

At the Board meetings of the Smalltalk Industry Council, I have repeatedly argued that Smalltalk must "Get with the Net" or will rapidly become a niche environment. As Bill Gates said at the Harvard Conference on The Internet and Society⁵ in May, 1996, if Microsoft didn't get with the net, Windows would be history. If the Internet is potentially capable of throwing Windows on the ash heap of history, it is certainly capable of doing the same to Smalltalk. The Smalltalk community must take immediate, aggressive action to respond to the challenges posed by Java and the Web. Smalltalk must become an Internet based development environment or become roadkill on the information highway. This Smalltalk Manifesto presents a plan of action that must be executed by the Smalltalk community quickly to avoid losing one of the best software development environments ever invented.

The Smalltalk Terminator: "Something Wicked This Way Comes"

"By the pricking of my thumbs, Something wicked this way comes, Open, locks, whoever knocks."⁶

Java is the cleverest attempt at a Trojan horse yet. The Netscape browser grabs screen real estate, sort of like grabbing shelf space in the local supermarket, and Java delivers the goods right into the heart of Microsoft territory and breaks their lock on the desktop. No wonder Bill Gates announced a counterattack on Pearl Harbor Day last December. Internet World dresses him up as a WWII General and outlines his strategy in the March, 1996 article, "Microsoft Declares War." Gates portrayed Microsoft as the suffering, innocent, American people while Netscape is billed as an unfeeling Japanese air strike on Pearl Harbor.⁷

The Netscape/Java combination is the first credible strategy to free the software industry from the iron grip of Microsoft. As a result, every leading software and hardware vendor has rallied around Java and Microsoft has had to join the pack and support Java in Microsoft products. Every major C++ vendor will become a Java vendor to survive in the C++ marketplace. Since C++ owns about 75% market share in object-oriented development environments. In the future, a substantial portion of the C++ market will turn into a Java market.

The popularity of Java is having a significant impact on Smalltalk developers, because Java can be viewed as a "Crippled Smalltalk for C++ Programmers." It avoids the complexity of C++ by introducing features which have been part of the Smalltalk environment for 20 years. More important, it can be seamlessly distributed over the World Wide Web, and runs on any system in the world that supports recent versions of the Netscape Navigator or Microsoft Explorer web browsers. It is free, totally portable, runs on every major hardware platform, and is supported by every major hardware and software vendor. Smalltalk is currently expensive, not very portable, does not run on all platforms, and is supported by a decreasing numbers of vendors who can be counted on the fingers of one hand.

Fortunately for Smalltalk, Java Can't Do Anything Really Useful Yet

Smalltalk is currently running in 15-20% of the production object-oriented, client/server business applications. Java is running in about 0% of these applications today. It is not robust, performance is poor, and is not ready for prime time. It is useful for cute applets on Web pages and not much else. In my current developments efforts for one of the leading Internet news providers, Individual, Inc., we are using Java for registration applets. Lack of tools, slow performance, and security restrictions are preventing us from using it more widely at the current time.

While Java has been designed to deal with the security issues posed by the Internet, it cannot effectively deal with client/server development on corporate intranets. For example, consider the security restrictions that are built into the Java applet execution environment:

· A Java applet can communicate only with the server that distributed the applet to the client machine.

· A Java applet cannot evoke an executable on a client machine.

· A Java applet cannot write to ROM or disk on a client machine.

Consider one of the simplest of all client/server applications, updating a local computer clock to atomic time. I use a Java application, TickTock⁸ that calls the U.S. Naval Observatory atomic clock server (violating security restriction 1), evokes an operating system call on my local machine (violating security restriction 2), and writes the current time to my system clock (violating security restriction 3). This is one of the simplest of all client/server applications and it cannot be run as an applet. Applets cannot do anything really useful.

Today, even Sun Microsystems does not recommend building major client/server production systems with Java. It's current perfomance and garbage collector limitations are similar to the first Smalltalks implemented in the 1970's. Nevertheless, Java currently stacks up pretty well against other major object-oriented languages. The table below originally appeared in "Smalltalk, C++, and OO COBOL: The Good, the Bad, and the Ugly"³ in 1995. Please review this earlier article for a description of the meaning of the table categores. A rating of 1 means Good, 2 means Ugly, and 3 means Bad.

The table is extended to include Java and has been critiqued by many members of the comp.lang.smalltalk, comp.lang.c++, and comp.object newsgroups. Despite isolated objections to particularly entries in the table, the ratings are adjusted to reflect a widespread consensus of opinion in the newsgroups. Java stacks up remarkably well for a new language.

Much of the leading compiler talent on the planet is currently dedicted to providing good Java tools, improving Java performance, giving Java a state-of-the-art garbage collector, and generally getting Java ready for prime time. As can be seen from the table below, with good tools, excellent performance, and a robust environment, Java will outrank Smalltalk as a software development language. I estimate that the Smalltalk community has about one year to respond to this problem.

Smalltalk, C++, OOCOBOL and Java: The Good (1), the Bad (3), and the Ugly (2)

		ST	C++	OOCOBOL	Java
Flexibility	Dynamic Binding	1	2	2	2
	Dynamic Classes	1	3	1	2
	Multiple Inheritance	3	2	2	3
	Roles/Interfaces	2	3	3	1
	Function pointers/lexical closure	1	2	3	3
Ease of use	Class Libraries	1	3	3	2
	Learning Curve	1	3	2	1
	Speed of Development	1	3	2	2
	Portability	2	3	3	1
Support	Tools	1	1	3	3
	Multiple Vendors	2	1	3	1
	Internet Aware	3	3	3	1
Performance		2	1	3	3
Risk	Garbage Collection	1	3	3	2
	Memory Leaks	1	3	1	1
	Overwriting Memory	1	3	1	1
	Ready for Prime Time	1	1	2	3
TOTAL	(low means best)	25	40	40	32

The Smalltalk Manifesto: Get Smalltalk With the Net!

In recent months I have participated in several board meetings of the Smalltalk Industry Council (STIC) and had extensive correspondence with management and technical staff of Los Alamos National Laboratories where many large Java projects are currently active. After reviewing these discussions with some of the leading Smalltalk consultants in the industry, the following strategy appears to leverage Smalltalk advantages and prepares Smalltalk to compete in Internet and Intranet environments.

1. Smalltalk applets must distribute over the net.

There are several strategies for dynamic distribution of Smalltalk applets. Smalltalk text could be distributed to a client where it could be interpreted locally. This would require a Smalltalk virtual machine on the client so it is not a very effective approach. Alternatively, a Smalltalk binary could be distributed as a binary OCX. This strategy is limited by the need for a Windows client and a Smalltalk client virtual machine. A third strategy is to distribute Smalltalk as a Java applet. This would allow Smalltalk to run anywhere, without the need for a Smalltalk virtual machine. The leading web browsers already support a Java virtual machine.

2. Smalltalk must be free.

A small team of Smalltalk and Java compiler experts could implement a simple Smalltalk environment that emitted Java byte codes in a few months. This should be funded through the Smalltalk Industry Council will the support of the leading Smalltalk vendors. It is clear from meeting with Smalltalk user groups all over the United States that such a product would be widely used and extended for Internet development work. The best Smalltalk tools, which are superior to C++ or Java development tools, would be rapidly ported to support such a Smalltalk.

3. Smalltalk must be standard.

This free Smalltalk should be implemented in compliance with the current draft of the ANSI X3J20 Technical Committee Smalltalk standard. It should be integrated and supported by all Smalltalk vendors for Web development. Vendors should compete on extended the standard environment and the quality of their class libarires and use a common virtual machine.

4. Smalltalk development tools must be used to support Java development.

Smalltalk development tools should be enhanced to support both Smalltalk and Java. Smalltalk compiler environments should emit either Smalltalk or Java byte codes as a compiler option.

Technical Issues

There is not space here to review all the technical problems that will be encountered when building a Smalltalk to emit Java byte codes. It will suffice to say that the current Java specification is sufficiently crippled that either (1) the resulting Smalltalk will be crippled, (2) Java will have to be extended and specialized to support a Java-based Smalltalk, or (3) the Java specification must be enhanced to properly support functionality that is basic to Smalltalk and should be fundamental to Java. Supporting block structures, lexical closure, and unlimited recursion come immediately to mind.

Most people favor the third approach. This would require that the Smalltalk community work with Sun JavaSoft to enhance the current Java specification. Some of the senior members of the Java compiler team at Sun are former Smalltalk developers and would favor this approach. There is already sematic information in the internals of the current release of Sun's Java compiler that could be easily exposed to the Java API that would begin to resolve some of these problems. Modifying the Java specification to properly support Smalltalk would "fix" some current crippling limitations and make Java a better cup of Java.

Why This Manifesto is Not Optional

The largest use of Smalltalk today is in corporate development environments for production business systems. New development in these environments is moving rapidly to Intranet solutions for the following reasons:⁸

· Thinner clients

· Reduced network costs

· Automated software distribution

· Lower cost software

· Easier maintenance

· Simpler technology for MIS to implement

· Distributed business object benefits

The Smalltalk community has about a year until Java has evolved enough to become the preferred Intranet development tool. Acting quickly on this Manifesto will assure the survival of Smalltalk and product a better Java. Both developers and the user community will win with better applications. Failure to act will result in Java eclipsing Smalltalk with inferior development tools that evolve out of current C++ environments. Everyone will lose.

Since this Manifesto can be implemented with a minimal amount of investment and Los Alamos National Laboratories has Java experts interested in starting work today, the Smalltalk Industry Council should convene an emergency meeting to implement this or an alternative proposal that produces equivalent results. It would be a shame to lose the best software development environment ever invented because of lack of vision on the part of the Smalltalk community.

References

1. Annual Report Technical Committee X3H7: Object Information Management. X3/95-0216 X O T, January 1995 - March 1995. <http://www.objs.com/x3h7/fmindex.htm>

2. Sutherland, Jeff. Smalltalk, C++, and OO COBOL: The Good, the Bad, and the Ugly. Object Magazine, 1995. <http://jeffsutherland.com/papers/oocobol.html>

3. Sutherland, Jeff. Objects, Databases, and the Web. Object World, 6 May 1996.

4. Carr, David. Adapt to Java or Risk Becoming Irrelevant, Smalltalk Programmers Are Told. Web Week, Volume 2, Issue 6, May 20, 1996.

5. Harvard Conference on The Internet and Society. May 28-31, 1996.

6. Lyall Watson quoting William Shakespeare. Dark Nature. Harper Collins, 1996.

7. Sutherland, Jeff. Road Kill on the Information Highway: JavaDay. Homepage.Journal, February 1996. <http://jeffsutherland.com/onemind/roadkill.html>

8. Sutherland, Jeff. Objects, Databases, and the World Wide Web: An Executive Overview of Object Technology and It's Killer App, the Internet. Tutorial: Object World Boston, 5 May 1996. <http://jeffsutherland.com/objwld98/index.html>