Cover Story (sidebar) / April 1998

Better Tools for Better Code

Tom R. Halfhill

Debates concerning the merits of various programming languages often reach a near-religious fervor. Not everyone shares the same priorities.

In the early days of computing, raw performance was the chief goal. When computers got faster, compiled languages, such as COBOL and C, largely replaced assembly language. This was because code portability and shorter development cycles became more important than maximum performance. When code reusability became an issue, object-oriented languages, such as C++, gained popularity. The 50-year trend in programming has been to trade off execution speed for more efficient development and higher levels of abstraction above the hardware.

Today, the most lively debate is over C/C++ (the standard for commercial software development) and Java (the newest language to achieve wide commercial appeal). It's no accident that Sun designed Java for high-level hardware abstraction, rapid development, and code safety.

The most often-cited difference between these languages is memory management. On the one hand, C/C++ requires programmers to manually allocate, manipulate, and deallocate memory. One of the most common bugs in C/C++ applications is a "memory leak" — the system gradually loses resources because a program keeps grabbing memory without giving it back. As the program consumes more and more memory, other processes become starved for resources until eventually there's a crash.

Java programs, on the other hand, are virtually leakproof because the Java virtual machine (JVM) manages memory, not the programmer. The JVM has an automatic garbage collector that frees up memory not being used by objects and data structures. The garbage collector eats up some CPU cycles, but it eliminates a huge source of bugs and crashes.

Likewise, Java stops programs from corrupting memory by automatically checking the bounds of all array references. You can't accidentally store data in the 101st element of a 100-element array, as you can in C/C++. Although you can purchase tools that add bounds-checking to C/C++, they're not universal.

There are dozens of less-publicized safety features in Java. For instance, another common flaw in C/C++ programs is poor error handling. It's easy to write a C/C++ program that has no error handling at all. In Java, if a class has a method that might throw an exception, a Java program must check for the exception, or it simply won't compile. Of course, you can still write sloppy error-handling code in Java, but Java at least ensures that some error trapping will be there.

Java also requires an explicit cast if a variable type conversion might lose precision. In C/C++, you can coerce a 64-bit double-precision floating-point value into a 32-bit single-precision floating-point variable without realizing it. Java requires an explicit cast, so you're at least aware that a precision error might result. This might seem like a small thing, but an Ariane 5 rocket exploded after liftoff in 1996 when a similar type mismatch caused an overflow that confused the inertial guidance system.

Perhaps the most controversial of Java's safety features is its single-inheritance model, as opposed to the multiple inheritance of C++. Classes can inherit methods from only one parent class, not from multiple parents. Java's designers believed this would reduce complexity and yield a cleaner class hierarchy.

C++ devotees insist on multiple inheritance. However, it's worth noting that Java actually does allow multiple inheritance — of interfaces, not implementations. A Java class can inherit the interface definitions of multiple parent classes (in other words, the method calls), but it must implement those methods itself. This protects the integrity of the child class if the method implementations in the parent classes change.

Java is by no means the only language to emphasize code safety. Eiffel, an object-oriented language developed by Bertrand Meyer in 1988, goes even further than Java in some ways. Eiffel requires methods to expose their calling parameters at run time. Most other languages, including Java and C/C++, rely on documentation for this purpose. Ada, a 1970s language developed for the U.S. Department of Defense, contains similar safeguards. But Java is the newest language to win broad support from tool vendors, developers, OS vendors, and schools.

Copyright 1994-1998 BYTE

Return to Tom's BYTE index page