Java for C++ Developers - Thinking Java

Start

When you first see Java code, you may think it looks a lot like C++. And it does. Deceptively so. The first and foremost rule is:

Despite the similarities in syntax, C++ and Java are worlds apart in language design.

Java needs a larger act of faith

If you made the move from C to C++, you may have felt that you were giving up some of the control you had over the machine because C++ did so much more for you "behind your back". Moving from C++ to Java gives you the same feeling. You have to trust the compiler even more than before.

Java simply doesn't give you as much low-level access. For example:

Standard data types have fixed sizes, not necessarily those most suited to the "natural" size of the machine.
There's no sizeof operator.
There's no union statement, sometimes used in C and C++ to manipulate bit representations of different data types.

Java discourages premature optimisation

We've all been told time and time again to make it run first, then make it run fast. But C++ by its very nature lends itself to some optimisation as you write (Inline functions are an example - it's almost automatic to declare some functions inline, even before doing performance profiling).

You pay a price, of course. Even with something as simple as inline functions, you're (a) exposing implementation information in header files; and (b) splitting implementation across two files, making it harder to understand and maintain.

Java doesn't give you as much control, so there's less temptation to optimise as you write. The basic idea is that you write sound and "correct" code, and leave it up to the compiler to do most of the optimisation. You can hand-optimise some things, but Java encourages you to do this later rather than earlier.

Java has less idioms

C++ and Java are both reasonably big languages. But C++ is even bigger because of all the tips, tricks and rules you need to know to program it well. Here are just a few:

The Rule of the Big Three: If you need a destructor, an assignment operator, or a copy constructor, you need all three.
If a class has at least one virtual function, it needs a virtual destructor.
Use pre- rather than post-increment operators because they are more efficient.
An assignment operator needs to be protected from assigning to itself.
Use const references for passing objects to functions rather than passing them by value.
Remember the lifetime of temporaries.

You get the idea...

Java has far less of these rules to remember. This is sometimes because it doesn't support the operations (operator overloading, for example), and sometimes because it does the work for you (automatic garbage collection, for example).

Java is a more modern language "If you don't use it, you don't pay for it"

C++ was intended to be a fast performer. As new features were added, care was taken to ensure that they wouldn't affect the performance of existing features. If you write some C++ using only the C subset of C++ of the language, it will probably run as fast as the native C code.
The corollary to this "user pays" rule is its main drawback: If you want it, you must ask for it. For example, it's more natural for member functions to be "virtual" by default (so that a base class designer doesn't have to guess which ones might want to be overriden in a derived class). But the ability to override member functions requires a slight drop in performance, so if you want this feature, you have to explicitly declare selected functions as `virtual`.
Java has been designed unencumbered by these constraints: There was no attempt to be compatible with C or C++ (although a lot of syntax has been borrowed from them); old compiler/linker technology didn't matter because Java needed to run over the Internet, which required new technology anyway; and some language design issues have taken priority over speed considerations.
In addition, Java has been able to take advantage of new language technology - for example, advances in automatic garbage collection and "just-in-time compiling".
Start