Comparison of Java and C++

Design aims

Language features

Syntax

• Java syntax has a context-free grammar that can be parsed by a simple LALR parser. Parsing C++ is more complicated. For example, Foo<1>; is a sequence of comparisons if Foo is a variable, but creates an object if Foo is the name of a class template.
• C++ allows namespace-level constants, variables, and functions. In Java, such entities must belong to some given type, and therefore must be defined inside a type definition, either a class or an interface.
• In C++, objects are values, while in Java they are not. C++ uses value semantics by default, while Java always uses reference semantics. To opt for reference semantics in C++, either a pointer or a reference can be used.

• In C++, it is possible to declare a pointer or reference to a const object in order to prevent client code from modifying it. Functions and methods can also guarantee that they will not modify the object pointed to by a pointer by using the "const" keyword. This enforces const-correctness.
• In Java, for the most part, const-correctness must rely on the semantics of the class' interface, i.e., it is not strongly enforced, except for public data members that are labeled final.

• C++ supports goto statements, which may lead to spaghetti code programming. With the exception of the goto statement, both Java and C++ have basically the same control flow structures, designed to enforce structured control flow, and relies on break and continue statements to provide some goto-like functions. Some commenters point out that these labelled flow control statements break the single point-of-exit property of structured programming.
• C++ provides low-level features which Java lacks. In C++, pointers can be used to manipulate specific memory locations, a task necessary for writing low-level operating system components. Similarly, many C++ compilers support an inline assembler. Assembly language code can be imported to a C program and vice versa. This makes C language even faster. In Java, such code must reside in external libraries, and can only be accessed via the Java Native Interface, with a significant overhead for each call.

  Semantics

• C++ allows default values for arguments of a function/method. Java does not. However, method overloading can be used to obtain similar results in Java but generate redundant stub code.
• The minimum of code needed to compile for C++ is a function, for Java is a class.
• C++ allows a range of implicit conversions between native types, and also allows defining implicit conversions involving user-defined types. In Java, only widening conversions between native types are implicit; other conversions require explicit cast syntax.
• * A result of this is that although loop conditions in Java and C++ both expect a boolean expression, code such as if will cause a compile error in Java because there is no implicit narrowing conversion from int to boolean, but will compile in C++. This is handy if the code was a typo and if was intended. However, current C++ compilers will usually generate a warning when such an assignment is performed within a conditional expression. Similarly, standalone comparison statements, e.g. a5;, without a side effect usually lead to a warning.
• For passing parameters to functions, C++ supports both pass-by-reference and pass-by-value. In Java, primitive parameters are always passed by value. Class types, interface types, and array types are collectively called reference types in Java and are also always passed by value.
• Java built-in types are of a specified size and range defined by the language specification. In C++, a minimal range of values is defined for built-in types, but the exact representation can be mapped to whatever native types are preferred on a given platform.
• * For instance, Java characters are 16-bit Unicode characters, and strings are composed of a sequence of such characters. C++ offers both narrow and wide characters, but the actual size of each is platform dependent, as is the character set used. Strings can be formed from either type.
• * This also implies that C++ compilers can automatically select the most efficient representation for the target platform, while the representation is fixed in Java, meaning the values can either be stored in the less-efficient size, or must pad the remaining bits and add code to emulate the reduced-width behavior.
• The rounding and precision of floating point values and operations in C++ is implementation-defined. Java provides an optional strict floating-point model that guarantees more consistent results across platforms, though at the cost of possibly slower run-time performance. However, Java does not comply strictly with the IEEE 754 standard. Most C++ compilers will, by default, comply partly with IEEE 754, but provide compliance options of varied strictness, to allow for some optimizing. If we label those options from least compliant to most compliant as fast, consistent, near-IEEE, and strict-IEEE, we can say that most C++ implementations default to near-IEEE, with options to switch to fast or strict-IEEE, while Java defaults to fast with an option to switch to consistent.
• In C++, pointers can be manipulated directly as memory address values. Java references are pointers to objects. Java references do not allow direct access to memory addresses or allow memory addresses to be manipulated with pointer arithmetic. In C++ one can construct pointers to pointers, pointers to ints and doubles, and pointers to arbitrary memory locations. Java references only access objects, never primitives, other references, or arbitrary memory locations.
• In C++, pointers can point to functions or member functions. The equivalent mechanism in Java uses object or interface references.
• Via stack-allocated objects, C++ supports scoped resource management, a technique used to automatically manage memory and other system resources that supports deterministic object destruction. While scoped resource management in C++ cannot be guaranteed it provides an effective means of resource management. Shared resources can be managed using shared_ptr, along with weak_ptr to break cyclic references. Java supports automatic memory management using garbage collection which can free unreachable objects even in the presence of cyclic references, but other system resources must be explicitly released because garbage collection is not guaranteed to occur immediately after the last object reference is abandoned.
• C++ features user-defined operator overloading. Operator overloading allows for user-defined types to support operators like primitive types via user-defined implementations for these operators. It is generally recommended to preserve the semantics of the operators. Java supports no form of operator overloading.
• Java features standard application programming interface support for reflection and dynamic loading of arbitrary new code.
• C++ supports static and dynamic linking of binaries.
• Java has generics, whose main purpose is to provide type-safe containers. C++ has compile-time templates, which provide more extensive support for generic programming and metaprogramming. Java has annotations, which allow adding arbitrary custom metadata to classes and metaprogramming via an annotation processing tool.
• Both Java and C++ distinguish between native types and user-defined types. In Java, native types have value semantics only, and compound types have reference semantics only. In C++ all types have value semantics, but a reference can be created to any type, which will allow the object to be manipulated via reference semantics.
• C++ supports multiple inheritance of arbitrary classes. In Java a class can derive from only one class, but a class can implement multiple interfaces.
• Java explicitly distinguishes between interfaces and classes. In C++, multiple inheritance and pure virtual functions make it possible to define classes that function almost like Java interfaces do, with a few small differences.
• Java has both language and standard library support for multi-threading. The synchronized keyword in Java provides simple and secure mutex locks to support multi-threaded applications. Java also provides robust and complex libraries for more advanced multi-threading synchronizing. Only as of C++11 is there a defined memory model for multi-threading in C++, and library support for creating threads and for many synchronizing primitives. There are also many third-party libraries for this.
• C++ member functions can be declared as virtual functions, which means the method to be called is determined by the run-time type of the object. By default, methods in C++ are not virtual. In Java, methods are virtual by default, but can be made non-virtual by using the final keyword.
• C++ enumerations are primitive types and support implicit conversion to integer types and may therefore define constructors, fields, and methods as any other class. As of C++11, C++ also supports strongly-typed enumerations which provide more type-safety and explicit specification of the storage type.
• Unary operators '++' and '--': in C++ "The operand shall be a modifiable lvalue. The result is the updated operand; it is an lvalue...", but in Java "the binary numeric promotion mentioned above may include unboxing conversion and value set conversion. If necessary, value set conversion is applied to the sum prior to its being stored in the variable.", i.e. in Java, after the initialization "Integer i=2;", "++i;" changes the reference i by assigning new object, while in C++ the object is still the same.

  Resource management

• Java offers automatic garbage collection, which may be bypassed in specific circumstances via the Real time Java specification. Memory management in C++ is usually done via constructors, destructors, and smart pointers. The C++ standard permits garbage collection, but does not require it. Garbage collection is rarely used in practice.
• C++ can allocate arbitrary blocks of memory. Java only allocates memory via object instantiation. Arbitrary memory blocks may be allocated in Java as an array of bytes.
• Java and C++ use different idioms for resource management. Java relies mainly on garbage collection, which can reclaim memory, while C++ relies mainly on the Resource Acquisition Is Initialization idiom. This is reflected in several differences between the two languages:
• * In C++ it is common to allocate objects of compound types as local stack-bound variables which are destroyed when they go out of scope. In Java compound types are always allocated on the heap and collected by the garbage collector.
• * C++ has destructors, while Java has finalizers. Both are invoked before an object's deallocation, but they differ significantly. A C++ object's destructor must be invoked implicitly or explicitly to deallocate an object. The destructor executes synchronously just before the point in a program at which an object is deallocated. Synchronous, coordinated uninitializing and deallocating in C++ thus satisfy the RAII idiom. In Java, object deallocation is implicitly handled by the garbage collector. A Java object's finalizer is invoked some time after it has been accessed for the last time and before it is deallocated. Very few objects need finalizers. A finalizer is needed by only objects that must guarantee some cleanup of the object state before deallocating, typically releasing resources external to the JVM.
• * With RAII in C++, one type of resource is typically wrapped inside a small class that allocates the resource upon construction and releases the resource upon destruction, and provide access to the resource in between those points. Any class that contain only such RAII objects do not need to define a destructor since the destructors of the RAII objects are called automatically as an object of this class is destroyed. In Java, safe synchronous deallocation of resources can be performed deterministically using the try/catch/finally construct.
• * In C++, it is possible to have a dangling pointer, a stale reference to an object that has already been deallocated. Attempting to use a dangling pointer typically results in program failure. In Java, the garbage collector will not destroy a referenced object.
• * In C++, it is possible to have uninitialized primitive objects. Java enforces default initialization.
• * In C++, it is possible to have an allocated object to which there is no valid reference. Such an unreachable object cannot be destroyed, and results in a memory leak. In contrast, in Java an object will not be deallocated by the garbage collector until it becomes unreachable. Garbage collection in Java prevents many memory leaks, but leaks are still possible under some circumstances.

  Libraries

• C++ provides cross-platform access to many features typically available in platform-specific libraries. Direct access from Java to native operating system and hardware functions requires the use of the Java Native Interface.

  Runtime

• Due to its unconstrained expressiveness, low level C++ language features cannot be reliably checked at compile-time or without overhead at run-time. Related programming errors can lead to low-level buffer overflows and segmentation faults. The Standard Template Library provides higher-level RAII abstractions to help avoid such errors. In Java, low level errors either cannot occur or are detected by the Java virtual machine and reported to the application in the form of an exception.
• The Java language requires specific behavior in the case of an out-of-bounds array access, which generally requires bounds checking of array accesses. This eliminates a possible source of instability but usually at the cost of slowing execution. In some cases, especially since Java 7, compiler analysis can prove a bounds check unneeded and eliminate it. C++ has no required behavior for out-of-bounds access of native arrays, thus requiring no bounds checking for native arrays. C++ standard library collections like std::vector, however, offer optional bounds checking. In summary, Java arrays are "usually safe; slightly constrained; often have overhead" while C++ native arrays "have optional overhead; are slightly unconstrained; are possibly unsafe."

  Templates vs. generics

Miscellaneous

• Java and C++ use different means to divide code into multiple source files. Java uses a package system that dictates the file name and path for all program definitions. Its compiler imports the executable class files. C++ uses a header file source code inclusion system to share declarations between source files.
• Compiled Java code files are generally smaller than code files in C++ as Java bytecode is usually more compact than native machine code and Java programs are never statically linked.
• C++ compiling features an added textual preprocessing phase, while Java does not. Thus some users add a preprocessing phase to their build process for better support of conditional compiling.
• Java's division and modulus operators are well defined to truncate to zero. C++ does not specify whether or not these operators truncate to zero or "truncate to -infinity". -3/2 will always be -1 in Java and C++11, but a C++03 compiler may return either -1 or -2, depending on the platform. C99 defines division in the same fashion as Java and C++11. Both languages guarantee that *b + a for all a and b. The C++03 version will sometimes be faster, as it is allowed to pick whichever truncation mode is native to the processor.
• The sizes of integer types are defined in Java, while in C++ the size of integers and pointers is compiler and application binary interface dependent within given constraints. Thus a Java program will have consistent behavior across platforms, whereas a C++ program may require adapting for some platforms, but may run faster with more natural integer sizes for the local platform.

Performance

• All objects are allocated on the heap. Though allocation is extremely fast in modern JVMs using 'bump allocation', which performs similarly to stack allocation, performance can still be negatively impacted due to the invocation of the garbage collector. Modern JIT compilers mitigate this problem to some extent with escape analysis or escape detection to allocate some objects on the stack, since Oracle JDK 6.
• Performance-critical projects like efficient database systems and messaging libraries have had to use internal unofficial APIs like sun.misc.Unsafe to gain access to manual resource management and be able to do stack allocation; effectively manipulating pseudo-pointers.
• A lot of run-time casting required even using standard containers induces a performance penalty. However, most of these casts are statically eliminated by the JIT compiler.
• Safety guarantees come at a run-time cost. For example, the compiler is required to put appropriate range checks in the code. Guarding each array access with a range check is not efficient, so most JIT compilers will try to eliminate them statically or by moving them out of inner loops.
• Lack of access to low-level details prevents the developer from improving the program where the compiler is unable to do so.
• The mandatory use of reference-semantics for all user-defined types in Java can introduce large amounts of superfluous memory indirections which can lead to frequent cache misses. Furthermore, cache-optimization, usually via cache-aware or cache-oblivious data structures and algorithms, can often lead to orders of magnitude improvements in performance as well as avoiding time-complexity degeneracy that is characteristic of many cache-pessimizing algorithms, and is therefore one of the most important forms of optimization; reference-semantics, as mandated in Java, makes such optimizations impossible to realize in practice.
• Garbage collection, as this form of automatic memory management introduces memory overhead.

• Java garbage collection may have better cache coherence than the usual use of malloc/new for memory allocation. Nevertheless, arguments exist that both allocators equally fragment the heap and neither exhibits better cache locality. However, in C++, allocation of single objects on the heap is rare, and large quantities of single objects are usually allocated in blocks via an STL container and/or with a small object allocator.
• Run-time compiling can potentially use information about the platform on which the code is being executed to improve code more effectively. However, most state-of-the-art native compilers generate multiple code paths to employ the full computational abilities of the given system. Also, the inverse argument can be made that native compilers can better exploit architecture-specific optimizing and instruction sets than multi-platform JVM distributions.
• Run-time compiling allows for more aggressive virtual function inlining than is possible for a static compiler, because the JIT compiler has more information about all possible targets of virtual calls, even if they are in different dynamically loaded modules. Currently available JVM implementations have no problem in inlining most of the monomorphic, mostly monomorphic and dimorphic calls, and research is in progress to inline also megamorphic calls, thanks to the recent invoke dynamic enhancements added in Java 7. Inlining can allow for further optimisations like loop vectorisation or loop unrolling, resulting in a huge overall performance increase.
• In Java, thread synchronizing is built into the language, so the JIT compiler can potentially, via escape analysis, elide locks, significantly improve the performance of naive multi-threaded code.

• Allowing pointers to point to any address can make optimizing difficult due to the possibility of pointer aliasing.
• Since the code generated from various instantiations of the same class template in C++ is not shared, excessive use of templates may lead to significant increase of the executable code size. However, because function templates are aggressively inlined, they can sometimes reduce code size, but more importantly allow for more aggressive static analysis and code optimizing by the compiler, more often making them more efficient than non-templated code. In contrast, Java generics are necessarily less efficient than non-genericized code.
• Because in a traditional C++ compiler, dynamic linking is performed after code generating and optimizing in C++, function calls spanning different dynamic modules cannot be inlined. However modern C++ compilers like MSVC and Clang+LLVM offer link-time-code-generation options that allow modules to be compiled to intermediate formats which allows inlining at the final link stage.

  Official standard and reference of the language

Language specification

Trademarks