Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Evaluating Java
So is Java a solution?
Java is a good language. In essence it is cleaned up C++. Many of the issues discussed previously disappear: It is simpler, and most of traps have been eliminated. However, it is not as functional as C++; there is a range of problems that would be hard to write in Java—in particular software, that needs to be close to the hardware or that needs high performance. For instance, I wouldn't write a games program or system software in Java. There is nothing wrong in this; Java has a different purpose. Java should be seen not as a replacement for C++, but as a replacement for COBOL. COBOL is a commercial language that has evolved over the years to fit the requirements of batch and OLTP programming, whereas Java is commercial language that (initially, at least) fits the requirements for distributed Web programming.
Learning Java, at least as a C++ programmer, is easy and takes, at most, a few days' work. But learning about the Java environment isn't so easy. The Java environment (the J2EE) is exposed to the Java program in a number of packages, and each package has a large number of class definitions. For instance, there are five java.security packages. There are 16 javax.swing packages as well as the java.awt package, all for handling the screen interface. There are packages for basic languages features, mathematical routines, database access, networking, middleware, string manipulation and internationalization, and many more. Yes, this is a clean environment in comparison with the Microsoft C++ environment, and we don't have to grapple with many nearly identical choices (although whether it will stay this way is questionable), but by no stretch of the imagination could it be described as easy.
So is Java better than, say, OO COBOL? As a programming language, I would say "yes." It is neater, less wordy, and easier to learn. But take away syntactic gloss, and the languages are surprisingly similar. Where Java has an assignment operator, OO COBOL has a MOVE statement. Where Java has if, OO COBOL has IF. Where Java has while, OO COBOL has PERFORM ... TEST BEFORE UNTIL .... A commonly praised feature of Java is automatic garbage collection, but OO COBOL has it, too.
The most significant differences in my mind are in the data structures. I can't find a feature of Java that cannot easily be implemented in OO COBOL. On the other hand, I can see several features in OO COBOL that don't exist in Java (automatic formatting using the PICTURE clause and using the INSPECT statement, to mention two). Suppose that you could arrange for an OO COBOL team and a Java team to implement the same application using the same database, the same middleware, and the same operating system. You would find that the OO COBOL solution has a small percentage of extra lines of code, but otherwise it has a similar size, complexity, and lucidity. You would not find an order of magnitude productivity difference between the two teams (given programmers of equal competence). Why should there be a difference? The amount of work that they have to do is practically identical.
But it is almost impossible to make that test because it is hard to find an environment that supports both OO COBOL and Java.
The true significance and power of Java lies in its portability and the J2EE environment. If you look at an application in which the environment offers little help—such as batch programming—you will see the language for what it is. What we have with Java is a simple language but an enormously complex runtime environment.