Since its release in 1983, C++ has gained a large following. In its time, C++ represented a natural upgrade path for projects that started with C but needed to migrate to a more disciplined language with improved abstraction and better scalability. However, Moore's law has foiled C++'s usefulness. As Anthony Scott, GM's Information Systems and Services CTO, recently explained, "More than one-third of the cost of GM's automobiles now involves software and electronic components, and the amount of software loaded into a typical automobile is skyrocketing... [It will] jump to 100 million [lines of code] by 2010."
When embedded software grows so large, the need for abstraction and scalability grows exponentially. This is where Java shines. With modern features like built-in support for multithreading, automatic garbage collection, secure dynamic class loading, simple syntax and semantics, strong type checking, consistent object orientation, and fully portable deployment of software components, Java developers are at least twice as productive as C++ programmers in creating new code and five to 10 times as productive as C++ developers in maintenance activities.
In fact, reuse and integration of independently developed embedded C++ components is difficult for a variety of reasons. First, the C++ standard makes specific provisions for implementation-dependent and implementation-defined language features where an integer might be 32 bits on one processor and 64 bits on another. Second, the C++ standard does not fully specify the behavior of the standard template libraries (STLs) or underlying operating-system services, nor does it standardize the collections of services needed from the operating system. Third, both the C++ language and the STLs are large, complex, and quite difficult to understand. Fourth, C++ does not offer automatic garbage collection. If the integration of components shares memory references between components, the system integrator must determine when those shared objects can be discarded and which component must reclaim memory.
A typical C++ component has buried within it hundreds of implicit dependencies on the target processor, C++ compiler, host operating system, and STLs. Assumptions are rarely documented, and most C++ programmers do not realize that the validity of their code depends on assumptions not necessarily valid in all execution environments. The typical C++ programmer simply tests and refines code until it works in the test environment.
Moving code to a new execution environment requires tremendous additional effort, including careful review of source code and thorough retesting of all boundary cases in the new execution environment. This almost always results in various revisions to the source code. In the final analysis, the C++ approach to software reuse is cost-prohibitive.
In contrast, customers consistently favorably report about their move to embedded Java development. Using Java, one customer developed a fault-tolerant distributed demonstration in only three days, even though it had previously budgeted a "solid three months" to implement the same capabilities using C/C++ targeted to a popular real-time operating system. Another customer described the final months of a multiyear project involving hundreds of developers, some working exclusively in C and others entirely in Java. In the final three months of the project, the customer told us, the Java programmers were nowhere to be seen while the C programmers were putting in overtime trying to find and correct lingering bugs.
A third customer explained that after a failed attempt to develop a complex multiservice telecommunications framework in C, it abandoned the project and rewrote the entire system in Java. The result was more functional, maintainable, and reliable. It completed the project with one-fifth the lines of source code and in half the time, even though it had to retrain the engineers in the use of Java.
Given trends for ever-increasing code size and complexity, the nationwide trend to train new computer scientists and software engineers in Java, and the well-documented productivity benefits of using Java, it's hard to imagine that anyone would start a new software development effort with C++.
Reprints
