By Jonathan Campbell

Many older programmers like me resist change. It is natural to the human species (and probably others) that changes in environment cause a certain amount of anxiety and discomfort. The dizzying changes that I have seen in my programming career – 30 years or so – would make most people's heads spin.

Which is why when I first heard of Java I was really not looking forward to learning to yet another new language. I had cut my teeth as a systems and language runtime system programmer on assembly language, then C, and (ugh) C++. I even liked the object-oriented approach that you could use in C++ if you didn't step on yourself by using older constructs of C.

When I took my first Java course, I was pleasantly surprised. It was enough like C that it was easy to write. The method library was huge; it seemed that you hardly had to write any code at all. The object approach made sense.

But some things made me uneasy about this language. Its "total break" from C seemed superficial. The difficulty of calling native methods written in C or C++ seemed absurdly difficult. The lack of destructors seemed odd, at best. When I pointed out to my Java instructor the obvious flaw in not having destructors – that other resources owned by structures deallocated by the garbage collector are lost forever – he said "yeah, you're right, I wonder why they didn't think of that."

Last year, at a going-away party for a friend who was a member of the ANSI Language Committee, I found out about something very odd. Somehow Sun Microsystems had convinced a majority of the committee to approve Java as a standard language, yet allow Sun to continue to be its sole proprietor and designer. This is the first time in the history of computing that this has happened. Previously any language that was approved as a standard was then maintained and modified only by the majority of the ANSI Committee for that language.

In the last year I watched and read about Java implementation projects. I found some disturbing trends:

1. The abstraction of Java objects, and the use of CORBA interprocess communication, seems to de-emphasize the planning, fault-tolerant design, and flow-charting of data. Exception handling is left to higher layers, causing major flaws to be overlooked. Performance considerations are left for the end, often revealing serious flaws in data flow designs.[1]

2. Performance of Java processes appear to be much slower than equivalent C or C++ processes, and it appears that the root causes are over-objectification (use of object method calls for simple data retrieval) and misuse of library methods (use of complex methods with lots of overhead to do simple tasks). There have been some phenomenal Java implementation failures (such as the Java project at Corel to re-implement some of Corel's core applications, which was abandoned). The elimination of structures and the necessity of calling object methods for obtaining any information about an object makes Java nearly impossible to optimize for a RISC processor; the instruction pipe is constantly being emptied as object methods are called.

3. Debugging of errant Java processes or threads is a nightmare. The use of the JVM and byte code, and the lack of ordinary crash dumps puts Java debugging in the same class as spraying batch FORTRAN programs with print statements.

The lack of destructors has led to exactly the kind of resource depletion errors that I had predicted with my Java instructor: sockets, file handles, and pipes attached to objects that are garbage-collected are lost.

Java applets, once thought to be the "future of the Web," suddenly lost popularity because of so-called hostile applets and byte-code viruses.[2] Most financial institutions and many other large corporations now block Java protocols at their firewall or have strict policies forbidding use of Java-enabled browsers.

Over-objectification transforms simple tasks into complex ones to fit into the object computing model. Thus, for instance, a simple database update call from a simple program gets transformed into invoking an "event generator" whose event is then noticed by an "event processor" which then invokes a call to a "database transport service" which then invokes a JDBC call that actually updates the database.

 

Then, in late October 1998, probably the most significant document ever written about computer industry practices – referred to as the Halloween Document – was spirited out of Microsoft. (See http://www.opensource.org/halloween.html.) It outlined a strategy proposed by a Microsoft analyst to destroy Linux and other so-called "open systems" (freeware) consortia. The strategy is to create new, complex protocols or extend public-domain ones in a way such as to make it impossible for the open software "competition" to keep up. With a staff of 14,000 software engineers, Microsoft can spin protocols and publish them faster than most organizations can write prototypes.

I realized immediately that I had seen this before at Digital, where I worked for 18 years. We spoke openly about "extending" protocols in a way that the competition would be unlikely to match. We would make the extension very desirable to customers (such as long passwords), and thereby "lock in" customers to Digital's "value-added" software and hardware products. I remembered how difficult it had been to convince the network engineering group to promote standard TCP/IP and stop adding features to DECnet.

Microsoft – and other companies – have been playing this game for a long time. Microsoft's "extensions" to C++ in VC++, promotion of Microsoft mail extensions and use of TNEF ("transport-neutral encapsulation format") instead of MIME, incompatibility of various versions of Microsoft Office, are all mechanisms used to keep customers buying and keep competitors off-balance.

Then I realized that somewhere in Sun there might be a similar document prepared when Java was being designed. (If there isn't, there are certainly a number of peculiar coincidences.) Seen in this light, Java is an absolutely masterful attempt to wean organizations and developers away from the Microsoft (VC++, MFC, VB) and open-software (straight procedural C) camps and into the Sun orbit. Let's see what that document would have said:

1. Design Java as a "replacement" technology to current language constructs, notably C and C++, without a lot of attention to compatibility or interoperability.

2. Instead of destructors, provide the Java environment garbage collector, making Java the darling of computer science professors everywhere, as well as "relieving" programmers of the need to provide messy cleanup routines for every object and string they create. The constructs needed for provision of a reliable garbage collector are very, very complex, making a successful implementation very attractive.

3. Make Java a "standard" language but convince the ANSI language standards body to allow Sun Microsystems to retain sole control of the language as a licensed entity.

4. Provide a huge method library that makes programming Java as easy as operating a toaster. (I don't think there is a single string, integer, or window manipulation for which there isn't now a standard Java method. The new JFC is certainly as prolific as MFC, if not more so.)

Let's look at these from the perspective I've outlined above, that is, to "gain market share" for Sun Microsystems.

1. Java essentially invalidates (deprecates) virtually the entirety of the world's software base, and promotes the use of a "better" language construct and environment that is owned, licensed and controlled by Sun Microsystems.

2. The lack of destructors and the provision instead of the asynchronous garbage collector makes an open-software implementation nearly impossible, and makes interfaces with other languages extremely problematic. It is also very attractive for "lazy" programming – not worrying about deallocation of memory.

3. Sun has twisted and distorted the work of the ANSI language committee in the case of Java. Every other language that is standardized by that committee also comes under the jurisdiction of the committee, by consent of the original company or university that promulgated the language. Here we have set a precedent: a private corporation retains absolute control over the language, with the ANSI committee becoming a rubber stamp.

4. It's hard to argue with simplicity. Even though the proliferation of methods has led to serious performance headaches and confusion over which methods to use, provision of all those methods allows for extremely rapid prototyping and deployment.

I have said to my friends that the only difference between Scott McNealy and Bill Gates is $40 billion in personal assets. I believe that the main focus of Java is precisely to move programmers and organizations from Microsoft's orbit to Sun's orbit (pardon the pun please). If this is not a conscious policy of Sun, it might as well be, because if Java is successful it will turn the tables around: instead of the "Windows monopoly," Sun will own the "Java/JVM monopoly."

Conclusions

It is the author's opinion that, like Microsoft and other companies in the computer industry, Sun's intentions in the creation of the Java language and environment, are not benevolent, but rather an attempt by Sun to hijack the entire computing industry by providing the "standard" platform. Because of the acceleration of speeds of non-Sun CPUs (Intel, AMD, and Compaq/Digital Alpha) and the competition from Microsoft and non-commercial freeware UNIX (Linux), general acceptance of the Java language and environment is a life-or-death issue for Sun.

Sun created Java in such a way that it deprecates billions of lines of C/C++ code, by encouraging organizations to adopt a new computing paradigm that is, at its core, incompatible with C/C++. The Java language itself has severe deficiencies, such as the deallocation of non-memory resources (the lack of destructors), which the author believes were necessary compromises – from the beginning – to prevent control outside the Sun-defined Java environment.

Sun has twisted and distorted the ANSI Language Standards process. Anti-Microsoft fervor allowed Sun to push the ANSI committee to approve Java as a national standard language yet allow Sun to retain complete control of it, turning this national standards body into a rubber stamp for Sun Microsystems.

The abstraction of objects fostered by Java – what the author refers to as "JavaThink" – appears to cause otherwise good software engineers to skip some of the usual steps involved in good software engineering practice, such as data flow analysis, fault tolerance, data persistence, and performance. Over-objectification also creates complexity from simple tasks.

Finally, the lack of structures and the need to use get/put methods for touching anything in an object makes instruction streams extremely short, making it physically impossible for Java programs to run anywhere near as fast as equivalent C/C++ programs on many current processors and certainly the majority of future processors.

As a 30-year veteran of the computing industry, I suggest that organizations take great care if they decide to adopt the "Java" environment, to be certain that it really matches the long-term needs of the organization, and that the off-the-shelf software available in the JDK and the marketplace really matches their requirements. The near-total deprecation of Java on the Web (due to security considerations), the serious problems enumerated above (especially the abandonment of billions of lines of public-domain and standardized code and libraries), and the ownership of the technology by a single private entity would make me think twice before adoption.

JLC

December 3, 1998

[1]The object abstractions, the functional independence of the methods, and the focus on the object interfaces (CORBA "services") tend to obscure – and in some cases even subvert – some of the fundamental functions of the system being built. In C, data (or a pointer to it) is passed and acted upon by procedures, whereas in Java the objects through which the data passes, rather than the data itself, become the primary focus. Perhaps these are just examples of poor system design – non-congruence of the object data and system data, for instance. But I have seen it too often to be coincidence. Even ordinary discussions about data flow analysis can be a frustrating experience, because in organizations that have embraced JavaThink people think in terms of objects and services – one step removed from the data and actions upon it.

[2] The emergence of hostile Java applets and bytecode viruses has dramatically reduced use of Java applets, I expect that by this time next year there will be no Websites that have Java client-side code. For more information about this, see http://www.rstcorp.com/hostile-applets