|
|
| Previous | Table of Contents | Next |
Gosler realized early on that C++ could not take on the role of a truly object-oriented, networked, development language. C++ was developed as an object-oriented update to C by Bjarne Stroustrup at AT&T Bell Labs in the early eighties. Although C++ is perhaps the most powerful language in the modern programmer’s tool chest, it undoubtedly has its faults, the least of which is that many popular compilers still do not even support the full functionality of the language. In any event, extending the extension of an extension, as it were, was not going to produce the language that the Green group was looking for in its distributed systems. It was decided that Java, which was then called Oak, would have to be an entirely new language.
To say that Java is a completely new language, however, is inaccurate. In fact, Java still retains much of the look and feel of C++. C++ is the dominant programming language today, and making Java much different would have cost programmers time and headaches in conversion that could have led to more errors in programming that risk the security of a client machine. Maintaining as much of the C++ style as possible was important, but in fact the language is a rewrite from the ground up.
Java is first and foremost an object-oriented language. Although C++ is considered object-oriented, it still enables programmers to write the same way they have always done— procedurally. Java forces the programmer to accept object-orientation from the beginning, eliminating the problem of combining two, dissimilar programming philosophies. Of course, in maintaining the look and feel of C++, it is easy to view Java in terms of what it does and does not retain from C++. In many cases, Java eliminates redundancies from C to C++ and any features that suggest procedural programming. Java added automatic boundary checking by eliminating the use of pointers and encapsulating arrays in a class structure and automatic garbage collection, in addition to many other features that made developing in C++ so difficult. These features are also the ones in C++ that create most errors in programs, such as the now infamous General Protection Faults that plagued the Windows 3.x environments.
The built-in memory management, in addition to the built-in multithreading features, is what makes Java an ideal language in which to program. The C++ language enables programmers to write code at a very low level. Thus, they are able to access hardware more efficiently and deal with memory addresses and individual bits efficiently. Although this creates very efficient programs, it is at the cost of portability and security because each program must be developed for an individual platform. Java eschewed this philosophy by ensuring that portability could be maintained by providing for all the bounds checking and memory management. At the same time, Java maintained its respectable performance by adding built-in threading functionality that could perform much of the garbage collection in a background process. The resulting Java code was assured to be robust and high performance.
In rewriting Java as a new language, the Green group was able to produce a feature rich, yet functionally compact specification. Extending C++ would have left much procedural residual that would only increase the size of an interpreter and slow down the overall performance, as well as make portability and robustness nearly impossible. Consider Java a reformed old friend who, after years of dragging along the old procedural habit, awoke clean and fresh as a wholly object-oriented person, devoid of the vestiges of the old ways.
Changes from C++
As mentioned previously, Java can be considered a derivative of C++. It was deliberately designed to look and feel like C++. Although this means that C++ programmers have an easier time converting to the new language, they must also drop some old habits. In learning Java, it is the differences that will present the most challenges for programmers. These differences include the following:
In addition, Java uses interfaces rather than header files. The role of #define has been subsumed by constants, and typedefs, structures, and unions are now the purview of Java’s classes. The argument for dropping these features is that C++ was riddled with redundancy; the class subsumes the role of the structure and union, so they are not needed separately. Its attempt to maintain compatibility with C meant that many features were being duplicated throughout the language specification. The use of #define was also considered by the Java development group to encourage difficult-to-read code, despite the fact that it was implemented as a way of clarifying code later in the development cycle.
Individual functions have been dropped from Java. Any functions you need must now be encapsulated in a class. In the same vein, Java drops multiple inheritance and replaces it with interfaces. The problems with fragile superclasses—a term used to refer to the unstable way that multiple inherited classes are used in C++—were considered too great. The interface in Java is the way that other classes see which methods a class can implement. Rather than letting out the whole structure of a class in header files, interfaces will only show the methods and final, or constant, variables.
Finally, goto, operator overloading, automatic coercion, and pointers are all gone. The goto statement has been decried in programming for years, yet it somehow hung around for some poor programmer stuck in a bind to fall in love with. Automatic coercions, which were allowed in C++, must now be explicitly called with a cast statement. An automatic coercion enables you to place an incompatible variable into another without explicitly saying you want the change. Unwanted loss of precision through automatic coercion is a common error in C++, and Java’s creators see this as a liability. Placing a signed 32-bit number into an unsigned number, for example, would make all numbers positive.
| Previous | Table of Contents | Next |