Java vs. C++?

Bruce Eckel’s Thinking in Java Contents | Prev | Next

Java
looks a lot like C++, and 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++ the
breakthroughs haven’t happened yet (it’s getting steadily faster,
but still hasn’t touched C++). Also, there seems to be a perking interest
in C++ in many fields, so I don’t think that language is going away any
time soon. (Languages seem to hang around. Speaking at one of my
“Intermediate/Advanced Java Seminars,” Allen Holub asserted that
the two most commonly-used languages are Rexx and COBOL, in that order.)

I’m
beginning to think that the strength of Java lies in a slightly different arena
than that of C++. C++ 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,
especially with tools like Microsoft Visual C++ and Borland C++ Builder (a
particular favorite of mine). These 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, from a language design
viewpoint it’s a mountain of hacks. 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.” You may or may not shudder
to hear this, but think about it: so much of Java is designed 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 intended to allow the
creation of very large and flexible bodies of code. Add to this the fact that
Java has the most robust type checking and error-handling systems I’ve
ever seen in a language and you have the makings of a significant leap forward
in programming productivity.

Should
you use Java instead of C++ for your project? Other than Web applets, there are
two issues to consider. First, if you want to use a lot of existing libraries
(and you’ll certainly get a lot of productivity gains there), or if you
have an existing C or C++ code base, Java might slow your development down
rather than speeding it up. If you’re developing all your code primarily
from scratch, then the simplicity of Java over C++ will shorten your
development time.

The
biggest issue is speed. Interpreted Java has been slow, even 20 to 50 times
slower than C in the original Java interpreters. This has improved quite a bit
over time, 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.)

You
can find comparisons of Java and C++, observations about Java realities and
practicality and coding guidelines in the appendices.

More by Author

Must Read