Java: It’s a good thing

Simson Garfinkel gives Java advocates plenty of things to talk about in his intriguing article “Java: Slow, Ugly, and Irrelevant” (Salon, January 2001). As a fan of Java, I felt compelled to formulate a more realistic perspective — albeit, in a forum for other Java fans. However, taking a step back from the technology we use on a daily basis proved to be an interesting experiment.

Is Java slow, ugly, and irrelevant?

In his article, Garfinkel leaves no room for doubt: he “hates” Java and feels the industry would be better off without it. Although I agree with numerous points he makes, I also feel he takes a somewhat simplistic and superficial look at Java. Let’s examine his arguments more closely.

Garfinkel highlights what he calls two “Big Lies” in Java: its speed and its “Write Once, Run Anywhere” promise of platform-independent computing. Both speed and portability are indeed important to Java, but I wouldn’t make conclusions about Java as a whole based on those two issues alone. That would be as naive as dismissing C++ merely because you can easily make memory-management bugs with it or because it’s a nightmare to use with shared libraries.

Is Java slow?

Let’s be fair. Java is not exactly the racecar of programming languages. Sure there are plenty of examples showing Java to be either incredibly fast or incredibly slow, but the reality is that most Java programs are heavyweights compared to their C- and C++-based equivalents. This translates to slower execution speed and more intensive memory usage.

The Java Virtual Machine (JVM) generates a significant portion of that overhead. Typically, Java programs are not directly executed by the computer’s hardware; instead, a special program, the virtual machine, runs the Java program. The benefits of having the JVM are Java’s flexible and powerful security architecture, the plug-in nature of Java components like servlets and applets, and the portability of compiled Java programs (.class files). In addition, most modern virtual machines also contain a just-in-time compiler that compiles Java byte-codes into native machine instructions to improve performance. But all of this comes at a price: the JVM consumes both processor time and memory while managing a Java program’s execution.

With standalone, GUI-based desktop applications, Java’s lack of speed is most obvious. I tend to agree with Garfinkel’s point; at this moment, Java is not ideal for developing desktop applications. These applications have several requirements that are not Java’s strong suits:

• Easy installation
• Fast and responsive user interfaces
• Ability to run on three-year-old computers
• Clean integration with Windows

From my own experience with Java, I’ve learned that easy installation is extremely important for the average Windows user. The extra step that Java needs for a virtual machine to execute a program complicates installation and adds a significant extra download. Also, most programmers don’t want to deal with the different Java versions and virtual machines. Most of the feedback I get from users involves installation problems. True, native executables have similar issues to deal with, but with Java they tend to be worse.

The second and third items in the above list are related. Java’s heavy resource consumption and sluggish execution speed make it score poorly in this area, especially on older computers. However, with careful programming, you can obtain acceptable results. In the case of the Java MD3 Model Viewer open source project I recently worked on, few people complained about the performance of the Java-based program; in fact the feedback I received was on the contrary.

This brings me to a related issue that Garfinkel strikes upon in his article. Careless programming can produce bad results in any language. Given that Java is not as fast as C by design, Java programmers should be especially careful to produce efficient code. Having lots of inexperienced programmers writing key Java code doesn’t help the situation. In this case, time is on Java’s side. The number of highly skilled Java programmers will grow, computer power will increase, and Java technology will continue to mature.

Regarding the fourth item above — clean integration with Windows — it is a fact that almost all desktop applications run on Windows. In a Windows-dominated world, platform independence is not a big advantage. And because of Java’s platform independence, it integrates less seamlessly with Windows. This is one of the reasons why I feel that the discontinuation of Microsoft’s J++ is unfortunate. That environment provided a way of writing Windows-specific programs in Java. To replace J++, Microsoft is currently developing C# (C-Sharp) — a language many Java developers may find similar to Java.

But all is not lost. There are numerous application domains where the requirements mentioned above do not play, or at least, are less important. I will discuss those further.

Write once, debug everywhere?

Does Java’s “Write Once, Run Anywhere” slogan really translate to “write once, debug/test everywhere” in practice? In my experience, no, it does not. Sometimes the small differences between Java implementations do indeed matter and need to be taken into account during development. This is again primarily the case in developing desktop applications. Having your user interface behave the same way on all platforms can be a daunting task.

For most programs wherein the user interface is not a key part of the application, Java’s platform independence does work nicely. If you keep a few rules in mind, like calling yield() to make your threads behave properly on OSs with cooperative multitasking (e.g., Mac OS), you’re likely to have very few problems. Sure it’s possible to write portable C code, but having a rich set of portable APIs at your disposal in Java makes the task much easier. Further, Java’s standardized and portable execution model using a virtual machine saves you from having to deal with the different ways in which operating systems load and execute binary code. All of this makes Java’s platform independence a real improvement over what existed before. As such, Java is definitely a necessary technology.

Is Java ugly?

In addition to the “Big Lies” mentioned above, Garfinkel also finds Java ugly and difficult to read. I absolutely don’t agree with his argument. From its inception, Java’s syntax tried to be a simpler, more usable form of the C++ syntax. Most people would agree that the C++ syntax is overly complicated and often obscure. Even though language beauty is subjective, I think the majority would find Java’s syntax simpler and more readable than that of C++. A good example is the declaration of an abstract method in a class. In Java you could write:

      public abstract void run();

In C++, you could write the equivalent as:

      public:
            virtual void run() = 0;

Java syntax does have its downside. The fact that primitive types are not objects leads to confusing code when you store primitives in an object data structure, for instance, a Vector. Automatic boxing of primitives, like in C#, could resolve this, but is not currently a Java feature. Still, I would argue that Java’s syntax is a big improvement over that of C++.

Where Java shines

So far I’ve mostly been talking about Java’s alleged disadvantages. But what about the areas where Java really shines?

A true benefit of Java is the programming environment it provides. The language syntax is simple, concise, and powerful. The use of interfaces as an alternative for multiple inheritance makes Java’s object model clearer and easier to understand. It also saves you from mountains of technical peculiarities, like name clashes and the complicated ways C++ tries to avoid them. Standardized tools, like JavaDoc, also make Java a pleasure to use. They’re available on all Java-enabled platforms, allowing you to choose among Linux, Windows, or anything else as your development environment.

When it comes to easy programming, the JVM also contributes a great deal. By taking care of memory management and linking (the process that allows the code in one .class file to interact with the code in another .class file), the JVM saves you from bugs and problems we know all too well from C++. For instance, the differing ways in which C++ compilers do name mangling and object layout complicates the use of shared libraries in C++. Further, the standard Java libraries, with their pattern-based, object-oriented approach, are easy to use compared with most of their C++ counterparts. In the end, Java is a language that allows you to concentrate on the problem at hand without being sidetracked by technical details.

That brings me to another big advantage of Java: time to market. Having a programming environment that saves you from making lots of common bugs and lets you concentrate on solving a specific problem greatly improves your productivity. This is also what makes programming in Java fun. You can quickly have your first versions up and running, providing you with early feedback and satisfaction.

Server-side programming is currently the area where Java really shines. Garfinkel acknowledges this in his follow-up article “Java Fans Fight Back,” and the reasons are obvious. Java’s benefits really pay off in a heterogeneous enterprise environment where different systems, ranging from Windows-based application servers to mainframe backends, need to cooperate. Having a common development and execution environment available on most of these systems is a real benefit. In addition, the Java 2, Enterprise Edition offers numerous APIs to interact with systems that might not directly support Java, using technologies like CORBA and JMS. Platform- and server-independence also avoids vendor lock-in, stable code improves service availability, and fast development cycles mean increased productivity and profitability.

On the server side, Java’s flaws have little importance. You can solve most of your performance problems with careful programming and high-end hardware, which is normally not a problem on the server side anyway. Also, GUIs don’t play the key role on the server side as they have in client desktop applications.

Java is also making progress in embedded computing, as Garfinkel admits. Java provides exciting possibilities in this area. Java facilitates developing applications for embedded systems and interoperating among different systems. Here is where Java’s platform independence flourishes as well, given the different hardware found in cell phones, handhelds, and smart cards.

Conclusion

Sure, Java is not perfect, but the picture that Garfinkel paints is overly bleak and naive. Labeling Java as irrelevant or just an anti-Microsoft ploy insults the many bright people who do find Java exciting, worthwhile, and fun! There are many software domains where Java’s benefits easily outweigh its drawbacks. Currently, this is especially true on the server side. Drawing conclusions about the whole of Java, based on just the desktop application domain, gives you a false impression of what is really an interesting technology.

Source: www.infoworld.com