Java vs. C++?

Java looks a lot like C++, so naturally it would seem that C++ will be replaced by Java. But Im starting to question this logic. For one thing, C++ still has some features that Java doesnt, and although there have been a lot of promises about Java someday being as fast or faster than C++, weve seen steady improvements but no dramatic breakthroughs. Also, there seems to be a continuing interest in C++, so I dont think that language is going away any time soon. Languages seem to hang around.

Im beginning to think that the strength of Java lies in a slightly different arena than that of C++, which is a language that doesnt try to fit a mold. Certainly it has been adapted in a number of ways to solve particular problems. Some C++ tools combine libraries, component models, and code-generation tools to solve the problem of developing windowed end-user applications (for Microsoft Windows). And yet, what do the vast majority of Windows developers use? Microsofts Visual BASIC (VB). This despite the fact that VB produces the kind of code that becomes unmanageable when the program is only a few pages long (and syntax that can be positively mystifying). As successful and popular as VB is, its not a very good example of language design. It would be nice to have the ease and power of VB without the resulting unmanageable code. And thats where I think Java will shine: as the next VB.[9] You may or may not shudder to hear this, but think about it: so much of Java is intended to make it easy for the programmer to solve application-level problems like networking and cross-platform UI, and yet it has a language design that allows the creation of very large and flexible bodies of code. Add to this the fact that Javas type checking and error handling is a big improvement over most languages and you have the makings of a significant leap forward in programming productivity.

If youre developing all your code primarily from scratch, then the simplicity of Java over C++ will significantly shorten your development timethe anecdotal evidence (stories from C++ teams that Ive talked to who have switched to Java) suggests a doubling of development speed over C++. If Java performance doesnt matter or you can somehow compensate for it, sheer time-to-market issues make it difficult to choose C++ over Java.

The biggest issue is performance. Interpreted Java has been slow, even 20 to 50 times slower than C in the original Java interpreters. This has improved greatly over time (especially with more recent versions of Java), but it will still remain an important number. Computers are about speed; if it wasnt significantly faster to do something on a computer then youd do it by hand. (Ive even heard it suggested that you start with Java, to gain the short development time, then use a tool and support libraries to translate your code to C++, if you need faster execution speed.)

The key to making Java feasible for many development projects is the appearance of speed improvements like so-called just-in-time (JIT) compilers, Suns own hotspot technology, and even native code compilers. Of course, native code compilers will eliminate the touted cross-platform execution of the compiled programs, but they will also bring the speed of the executable closer to that of C and C++. And cross-compiling a program in Java should be a lot easier than doing so in C or C++. (In theory, you just recompile, but that promise has been made before for other languages.)