Java is taking us in the wrong direction

Why Java will not live up to the hype surrounding it

There's a tremendous amount of hype in the popular press about the Java language these days. Some developers are claiming that it's the holy grail of application portability. The pundits are saying that it may be the stake in Microsoft's heart that the world has been waiting for. The popular press has latched on to it a symbol for how the Internet will come to affect everyone's life, and Sun and Netscape's stock has soared.

But these beliefs could stand some scrutiny. Here are some of the major claims made about Java, each followed by a critical analysis of it. See also our Guide to High-Level Development Languages for a list of questions to ask before choosing a development tool.

1) Java is the first truly portable GUI development language

Portable GUI toolkits have been available for over a decade. Products like XVT, Open Interface, Galaxy, and a many others have allowed developers to produce applications that run on any platform with a simple recompile. Many of these tools have been reasonably successful products, but none have garnered anywhere near the degree of hype and adulation that Java has. Why?

Is it because Java has better GUI tools?

No. On the contrary, the Java's AWT is undoubtedly the most primitive GUI toolkit of any cross-platform environment (see the PIGUI FAQ (Platform Independent Graphical User Interface) pointers to some of the alternatives with descriptions of their design and capabilities). To build anything that requires controls other than simple buttons and fields requires lots of low-level coding, or locating (and probably paying for) a piece of code written by another developer and integrating it into your application.

Is it because Java has an interpreter?

No, since many portable fourth-generation languages (4GLs) and Very High Level Languages (VHLLs) have interpreters, which allow the same program to be run on multiple platforms.

Is it because Java is a more productive language?

Far from it. In fact, compared with most of these other environments, Java is probably the lowest-level language one could use for GUI development. The GUI builders and graphical language and debugging tools, Java today is where most of these tools were 5 years ago.

Is it because Java is faster than other interpreted languages?

Benchmarks of Java vs. Perl, MetaTalk, and other languages with advanced "virtual compilation" technology show that Java has virtually no performance advantages. And due to the lack of high-level language features (or the fact that they must be implemented as Java class libraries), most Java applications will probably run slower than Perl or MetaTalk equivalents.

JIT compilers may improve execution performance somewhat in some applications, but forcing the end-user to wait while the application is recompiled on their machine (using most or all of the resources of machine for the duration) will probably erase this benefit in most cases.

Is it because Java applications can be extended with class libraries?

Possibly, but this is not actually much of an advantage because the code in these class libraries must be interpreted. A much better approach for the majority of application development is to use a language and development environment that has sufficient power that it doesn't require extensions to implement the majority of applications. Java, takes the opposite approach, requiring add-on code to complete even the most trivial of applications. This inability to leverage large amounts of compiled code is the single largest weakness of Java vs. other interpreted languages. For example, in the Java Cup demo available from the MetaCard Stacks page, it is shown that running a simple animation in Java requires over 10 times the CPU time required to run the same animation in MetaCard. There are two causes for this. First, MetaTalk is a higher level language than Java and so fewer statements are required to achieve the same results. Since the MetaTalk interpreter is about as fast as the Java interpreter, fewer statements translates directly into faster execution. Secondly, and more importantly, is the "leverage" factor: a MetaCard statement calls directly into highly-optimized compiled C++ code. The Java interpreter, on the other hand, must wade through hundreds or even thousands of lines of interpreted code in the class libraries to achieve the same ends, paying the price in performance between interpreted and compiled code with every statement.

Is it because Java applications can be delivered via the WWW?

Possibly, but then so can applications developed with a wide range of other tools including MetaCard. Almost all of these tools can be used as "helper applications" now, and many of them are available as plug-ins or even as complete replacements for browsers.

Is it because Java is free?

Quite likely. Never underestimate the power of free software (witness the success of Mosaic, then Netscape, and indeed of the WWW itself). Add in the "bandwagon effect" and the great popularity of Java can be understood without even making a detailed analysis of its technical merits.

2) Java can do things no other language can do.

Java is an interpreter, which means it can run applications on any platform without recompiling. So can Basic, Perl, MetaTalk/HyperTalk and a large number of other languages. Java does have features that allow untrusted code to be run without possibly jeopardizing security, but adding this feature to these other languages is a trivial matter, and it has already been implemented in MetaCard and Shockwave (the Macromedia Director player). Java also has good low-level communications support for WWW-based applications, but again adding these features (or even better, high-level substitutes) to other languages would be straightforward.

Java also supports multithreading, a powerful but extremely rarely essential and exceedingly difficult to use programming paradigm. Given a sufficiently advanced time-based event scheduler, such as those available in MetaCard and Macromedia Director, no application developer should even be tempted to try to manage a multi-threaded application.

The greatest potential advantage of Java in the WWW environment where people can download applications (applets) automatically for free. But how many companies stay in business by giving away software? (besides Netscape, I mean ;-) And if you're going to pay for software, presumably because you're going to use it more than once, is it really that big a burden to download a binary component? Indeed, a binary component has large advantages over a Java applet: it will start up faster since it doesn't have to be downloaded each time it is run, it will run much faster, and it can do anything it needs to to get the job done (whereas Java's security will prevent it from doing many or even most important things). And as for the security argument: if you don't trust a company not to break into or corrupt your system, do you really want to send them money anyway?

This use of Java in WWW pages is likely to have an even more damaging impact on the development of the Internet: by allowing the content providers complete control over the presentation of their information, Java removes the incentive to push for standardization of information formats. For example, all the major shipping companies are working on Java-based applications for presentation of their scheduling and pricing information. But what users of this really want to use this information for is to make comparisons between companies. By locking up the data in proprietary formats only understood by the Java applet, comparisons become impossible to make. This will set back the development of information format standards similar to those widely used for purchasing (Electronic Data Interchange or EDI) by many years.

The architecture-equalizing effect of having Java interpreters available for all processor types deserves mention. While it's true that this could be an advantage if there were a huge number of processor types, as it turns out there aren't that many of any significance. A handful of processor types make up more than 99% of the installed base of general-purpose computers. It doesn't make too much sense for the world as a whole to make their development language choices based on what's good for a hardware vendor that wants to introduce yet another architecture for hand-help computers. Those that want to survive will get application support, an easy thing to do given a much undervalued, but widely available, technology: cross compilers.

3) Java is a high-level language for GUI development

On a pure lines-of-code (LOC) basis, implementing a simple application in Java will take many more LOC as implementing the same application using a VHLL like Perl, Tcl, or MetaTalk. The gap widens for more complex applications because Java lacks so many of the built-in data manipulation features found in these other languages (e.g. regular expression pattern matching and associative arrays). Though to some extent the gap will be closed by class libraries that are becoming available for Java, the serious maintenance issues that arise when using bits and pieces of code from many different sources will prevent this from being a successful strategy (witness the great success of component-ware like VBXs at the expense of "reuse" as espoused by OO programming zealots).

LOC required is a direct correlate of time to complete an application. Choosing Java therefore means choosing to release an application later than would be possible by using a different language.

4) Java is an open standard

Licensing the Java runtime environment costs $125,000, putting it out of reach of the most of ISVs who would like to include support for Java applets in their applications. Java is therefore destined to cause a fracturing of the Internet into have and have-nots as smaller WWW browser vendors (and other application vendors) will be unable to include the ability to run Java applets. This situation may or may not be improved by OEMs licensing Java on a per-OS level, because these vendors probably won't make Java available on their older OSs.

Furthermore, Sun and only Sun controls the development of the Java language. Indeed, Java licensees who make improvements to the language are required to turn these improvements back over to Sun as condition of their licenses.

Java is at least as proprietary as Visual Basic and 4GLs , and all of these are more proprietary than HyperTalk/MetaTalk/SuperTalk (since there are multiple independent yet interoperable implementations of the latter language).

5) Compiled Java is (will be) as fast as compiled C/C++

Though removing pointers and explicit memory management from the language will simplify development in some cases, it does come with a performance penalty. For example, implementing matrix multiplication in C/C++ using pointers is from 30% to over 300% faster than using array indices as is required by Java. This doesn't even include bounds checking overhead which downloaded Java applets will require even when compiled. Garbage collection and the inability to allocate arbitrary sized chunks of memory and turn them into objects (a dangerous C++ technique with considerable performance benefits) further cripple Java.

Note that JIT compilation is not a solution to this problem. In fact, it actually magnifies it because Java applications must be compiled twice: once on the developers machine (to Java VM byte-code) and then again on the user's machine. The user will be forced to wait for this second compile before being able to use the application. This delay is extremely disruptive, and huge amounts of effort will have to be expended to minimize it. Unfortunately, Java won't be part of the solution, because as Sun discovered when they tried to write a JIT compiler in Java, the language is inherently too slow for this application and so they will be using a JIT compiler written in C or C++ (See page 136 of the Sept 16, 1996 issue of InformationWeek for details).

Even if Java is compiled directly to machine code, it will never be as fast as C or C++, and users are unwilling to give up even 30% of the performance they paid for just to make developers' lives a little easier.

6) Using Java is a good way to put animation into WWW pages

Java has very primitive built-in multimedia capabilities. Plug-ins such like Macromedia Shockwave (the Director plug-in) are much easier to develop for and offer many more animation and multimedia features than Java. Furthermore, multimedia presentations (and WWW pages themselves, for that matter) are almost always produced by graphic artists and writers and other non-professional programmers. Due to its low-level nature, Java is a completely unsuitable language for these content developers. Since the plug-in architecture can be used by any company developing multimedia authoring tools, using Java for this will soon become impractical. See the Java Cup demo available from the MetaCard Stacks page for examples of how weak Java is in this role.

Bottom line

Clearly Java cannot be just be dismissed as another flash-in-the-pan. Merely by virtue of the current widespread interest in it, it will undoubtedly become an important tool for developing Internet applications. But as it becomes more common for special purpose applications (like spreadsheets and word processors) to have Internet connectivity built in, the ability to enhance general-purpose WWW browsers with these capabilities will become less and less important. CORBA and ActiveX also will make serious inroads into the areas that are Java's forte. By not forcing a developer to use a particular language, these standards have big advantages over Java. They are also much more feature-rich standards, and will support applications that will not be possible to build with Java-enhanced browsers.

Since Java lacks a standardized inter-object communication system, developers are currently busy making up proprietary messaging standards to solve todays problems. By delaying acceptance of CORBA and OpenDoc, Java is probably also going to set back the development of the Internet tools we all really need by many years.

The bottom line is that though Java is a good solution for some types of problems, these problems are actually few and far between. Developers choosing a development language should seriously consider all of their options before blindly jumping on the bandwagon. To do otherwise risks missing deadlines and ending up with low-performance, low-functionality products which have the sole advantage that they can be given away free very easily.

For more criticisms of Java see the results of a survey conducted by Market Decisions Corporation and published on Yahoo

Questions? Comments? Email to www@metacard.com

Back to IDE Table of Contents