View source for Comparison of Java and C++

{{Short description|Comparison between two programming languages}}
{{Multiple issues|
{{unbalanced|date=May 2016}}
{{self-published|date=September 2010}}
{{original research|date=August 2012}}
}}
{{ProgLangCompare}}

[[Java (programming language)|Java]] and [[C++]] are two prominent [[Object-oriented programming|object-oriented]] [[Programming language|programming language]]s. By many language popularity metrics, the two languages have dominated object-oriented and high-performance software development for much of the 21st century, and are often directly compared and contrasted. Java's syntax [[Software:Java (software platform)#History|was based on C/C++]].

== Design aims ==
The differences between the programming languages C++ and Java can be traced to their [[Virtual heritage|heritage]], as they have different design goals.

C++ was designed for systems and applications programming (i.e., infrastructure programming), extending the [[Procedural programming|procedural programming]] language [[C (programming language)|C]], which was designed for efficient execution. To C, C++ added support for [[Object-oriented programming|object-oriented programming]], [[Exception handling|exception handling]], lifetime-based resource management (Resource Acquisition Is Initialization (RAII)), [[Generic programming|generic programming]], [[Template metaprogramming|template metaprogramming]], and the [[Software:C++ Standard Library|C++ Standard Library]] which includes generic containers and algorithms (the [[Standard Template Library]] or STL), and many other general purpose facilities.

Java is a general-purpose, concurrent, class-based, object-oriented{{sfn|Bloch|2018|loc=Foreword|pp=xi-xii}} programming language that is designed to minimize implementation dependencies. It relies on a [[Java virtual machine]] to be [[Computer security|secure]] and highly [[Porting|portable]]. It is bundled with an extensive library designed to provide abstraction of the underlying platform. Java is a statically typed object-oriented language that uses a syntax similar to (but incompatible with) C++. It includes a documentation system called [[Software:Javadoc|Javadoc]].

The different goals in the development of C++ and Java resulted in different principles and design trade-offs between the languages. The differences are as follows:

{| class="wikitable"
! style="width:50%;"| C++
! style="width:50%;"| Java
|-
| Extends [[C (programming language)|C]] with [[Object-oriented programming|object-oriented programming]] and [[Generic programming|generic programming]]. C code can most properly be used.
| Strongly influenced by C++/C syntax.
|-
| Compatible with [[C (programming language)|C]] source code, except for a few [[Corner case|corner case]]s.
| Provides the [[Java Native Interface]] as well as [[Software:Java Native Access|Java Native Access]] and more recently [[Java Native Interface#Foreign Function and Memory API|Foreign Function and Memory API]] as a way to directly call C/C++ code. However, native languages are not safe and applications using native methods are susceptible to memory corruption.{{sfn|Bloch|2018|loc=Chapter §11 Item 66: Use native methods judiciously|p=285}} If the code is not carefully written, native methods can lower the performance of the system because the garbage collector is incapable of monitoring or maintaining native memory usage, and there is a cost context-switching between native and non-native code.{{sfn|Bloch|2018|loc=Chapter §11 Item 66: Use native methods judiciously|p=285}}
|-
| [[Write once, compile anywhere]] (WOCA).
| [[Write once, run anywhere]]/everywhere (WORA/WORE).
|-
| Allows [[Procedural programming|procedural programming]], [[Functional programming|functional programming]], [[Object-oriented programming|object-oriented programming]], [[Generic programming|generic programming]], and [[Template metaprogramming|template metaprogramming]]. Favors a mix of paradigms.
| Allows [[Procedural programming|procedural programming]], [[Functional programming|functional programming]] (since Java 8) and [[Generic programming|generic programming]] (since Java 5), but strongly encourages the [[Object-oriented programming|object-oriented]] [[Programming paradigm|programming paradigm]]. Includes support for creating [[Scripting language|scripting language]]s.
|-
| Runs as native executable machine code for the target instruction set(s).
| Runs on a [[Java virtual machine|virtual machine]].
|-
| Provides object types and type names. Allows [[Reflective programming|reflection]] via [[Run-time type information|run-time type information]] (RTTI) as well as <code>std::meta</code> (since [[C++26]]).
| Is reflective, allowing [[Metaprogramming|metaprogramming]] and dynamic code generation at runtime using <code>java.lang.reflect</code>.
|-
| Has multiple binary compatibility standards (commonly Microsoft (for MSVC compiler) and Itanium/GNU (for almost all other compilers)).
| Has one binary compatibility standard, [[Cross-platform|cross-platform]] for OS and compiler.
|-
| Optional automated [[Bounds checking|bounds checking]] (e.g., the <code>at()</code> method in container types like <code>std::vector<T></code> and <code>std::string</code>).
| All operations are required to be bound-checked by all compliant distributions of Java. [[Software:HotSpot|HotSpot]] can remove bounds checking.
|-
| Native unsigned arithmetic support.
| Native unsigned arithmetic unsupported. Java 8 changes some of this, but aspects are unclear.<ref>{{Cite web | url=https://blogs.oracle.com/darcy/entry/unsigned_api | title=Unsigned Integer Arithmetic API now in JDK 8 | access-date=17 March 2014 | archive-date=25 February 2017 | archive-url=https://web.archive.org/web/20170225213350/https://blogs.oracle.com/darcy/entry/unsigned_api | url-status=dead }}</ref>
|-
| Standardized minimum limits for all numerical types, but the actual sizes are implementation-defined. Standardized types are available via the standard library <code><cstdint></code>.
| Standardized limits and sizes of all primitive types on all platforms.
|-
| Pointers, references, and pass-by-value are supported for all types (primitive or user-defined).
| All types (primitive types and reference types) are always passed by value.<ref>{{cite web |url= http://download.oracle.com/javase/tutorial/java/javaOO/arguments.html |title= The Java Tutorials: Passing Information to a Method or a Constructor |publisher= Oracle |access-date=17 February 2013}}</ref>
|-
| [[Memory management]] can be done [[Manual memory management|manually]] via <code>new</code> and <code>delete</code>, automatically by scope, or by smart pointers. Supports deterministic destruction of objects.

A [[Garbage collection (computer science)|garbage collection]] ABI was standardized in C++11, but was implemented by few compilers and removed from the standard in C++23.
| Automatic [[Garbage collection (computer science)|garbage collection]].{{sfn|Bloch|2018|loc=Chapter §2 Item 7: Eliminate obsolete references|pp=123-125}} Supports a non-deterministic <code>java.lang.Object::finalize()</code> method, use of which is not recommended.<ref>{{cite web |url= http://docs.oracle.com/javase/tutorial/java/IandI/objectclass.html |title= The Java Tutorials: Object as a Superclass |publisher= Oracle |access-date=17 February 2013}}.</ref>{{sfn|Bloch|2018|loc=Chapter §2 Item 8: Avoid finalizers and cleaners|pp=29-33}}
|-
| [[Resource management (computing)|Resource management]] can be done manually or by automatic lifetime-based resource management (RAII).
| Resource management must generally be done manually, or automatically via finalizers, though this is generally discouraged. Has try-with-resources for automatic scope-based resource management (version 7 onwards). Resources, such as memory, can be managed using [[Java Native Interface]] or the Java Foreign Function and Memory API (since Java 22), but requires calling external C/C++ code.

It can also be done using the internal API [[Security of the Java software platform#The sun.misc.Unsafe class|<code>sun.misc.Unsafe</code>]] but that usage is highly discouraged and will be replaced by a public API in an upcoming Java version.
|-
| Supports classes, structs ([[Passive data structure|passive data structure]] (PDS) types), and unions, and can allocate them on the [[Dynamic memory allocation|heap]] or the [[Stack-based memory allocation|stack]].
| Classes are allocated on the [[Dynamic memory allocation|heap]]. [[Java version history#Java SE 6|Java SE 6]] optimizes with [[Escape analysis|escape analysis]] to allocate some objects on the [[Stack-based memory allocation|stack]]. 
|-
| Allows explicitly overriding types, and some implicit narrowing conversions (for compatibility with C).
| Rigid [[Type safety|type safety]] except for widening conversions.
|-
| The [[Software:C++ Standard Library|C++ Standard Library]] was designed to have a limited scope and functions, but includes language support, diagnostics, general utilities, strings, locales, containers, algorithms, [[Iterator#C++|iterators]], numerics, input/output, random number generators, regular expression parsing, threading facilities, type traits (for static type introspection) and Standard C Library. Networking is a planned feature but not finalized yet. The [[Software:Boost (C++ libraries)|Boost library]] and [[Software:POCO C++ Libraries|POCO C++ Libraries]] offer more abilities.
A rich amount of third-party libraries exist for GUI and other functions like: [[Software:Adaptive Communication Environment|Adaptive Communication Environment]] (ACE), [[Software:Crypto++|Crypto++]], various [[XMPP]] Instant Messaging (IM) libraries,<ref name="XMPP Software » Libraries">{{cite web|title=XMPP Software » Libraries|url=http://xmpp.org/xmpp-software/libraries/|publisher=xmpp.org|access-date=13 June 2013}}</ref> [[Software:OpenLDAP|OpenLDAP]], [[Software:Qt|Qt]], [[Software:Gtkmm|gtkmm]].
| The standard library has grown with each release. By version 1.6, the library included support for locales, logging, containers and iterators, algorithms, GUI programming (but not using the system GUI), graphics, multi-threading, networking, platform security, introspection, dynamic class loading, blocking and non-blocking I/O. It provided interfaces or support classes for [[XML]], [[XSLT]], [[MIDI]], database connectivity, naming services (e.g. LDAP), cryptography, security services (e.g. [[Software:Kerberos (protocol)|Kerberos]]), print services, and web services. SWT offered an abstraction for platform-specific GUIs, but was superseded by [[Software:JavaFX|JavaFX]] in the latest releases; allowing for graphics acceleration and CSS-themable UIs. Although it doesn't support any kind of "native platform look" support.
|-
| [[Operator overloading]] for most operators. Preserving meaning (semantics) is highly recommended.
| Operators are not overridable. The language overrides <code>+</code> and <code>+=</code> for the <code>String</code> class.
|-
| Single and [[Multiple inheritance|multiple inheritance]] of classes, including virtual inheritance.
| Only supports single inheritance of classes,{{sfn|Bloch|2018|loc=Foreword|pp=xi-xii}} however interfaces may multiply extend other interfaces and classes may implement multiple interfaces.
|-
| Compile-time templates. Allows for Turing complete meta-programming.
| [[Generics in Java|Generics]] are used to achieve basic type-parametrization, but they do not translate from source code to byte code due to the use of [[Type erasure|type erasure]] by the compiler. Java type-casts all generics to their lowest bound (<code>java.lang.Object</code> if no such bound exists, otherwise <code>? extends T</code> is cast to <code>T</code>).
|-
| Function pointers, function objects, lambdas (in [[C++11]]), and interfaces (using abstract classes).

[[C++26]] introduces <code>^^T</code> (of type <code>std::meta::info</code>), which represents a type metadata.
| Functions references, function objects and lambdas were added in Java 8. Classes (and interfaces, which are classes) can be passed as references.

Java denotes a type metadata with <code>T.class</code> (of type <code>java.lang.Class<T></code>) or <code>T::getClass()</code> (which returns <code>java.lang.Class<?></code>).
|-
| No standard inline documentation mechanism. Third-party software (e.g. [[Software:Doxygen|Doxygen]]) exists. Standard library vendors may provide documentation comments, though it is not guaranteed.
| Extensive [[Software:Javadoc|Javadoc]] documentation standard on all system classes and methods.
|-
| <code>const</code> keyword for defining immutable variables and member functions that do not change the object. Const-ness is propagated as a means to enforce, at compile-time, correctness of the code with respect to mutability of objects (see const-correctness).
| <code>final</code> provides a version of <code>const</code>,{{sfn|Goetz|Peierls|Bloch|Bowbeer|2006|loc=§3.4.1 Final fields|p=48}} equivalent to <code>T* const</code> pointers for objects and <code>const</code> for primitive types. Immutability of object members achieved via read-only interfaces and object encapsulation. 
|-
| Supports the <code>[[Goto|goto]]</code> statement.
| Supports labels with loops and statement blocks. <code>goto</code> is a reserved keyword but is marked as "unused" in the [https://docs.oracle.com/javase/specs/ Java specification.]
|-
| Source code can be written to be [[Cross-platform|cross-platform]] (can be compiled for BSD, [[Software:Linux|GNU/Linux]], [[Software:MacOS|macOS]], [[Software:Solaris (operating system)|Solaris]], [[Software:Microsoft Windows|Windows]],  etc., without modification) and written to use platform-specific features. Typically compiled into native machine code, must be recompiled for each target platform.
| Compiled into [[Java bytecode]] for the JVM. Byte code is dependent on the Java platform, but is typically independent of [[Operating system|operating system]] specific features.
|}

== Language features ==

=== Syntax ===
{{see also|Java syntax|C++ syntax}}
* [[Java syntax]] has a [[Context-free grammar|context-free grammar]] that can be parsed by a simple [[LALR parser]]. Parsing C++ is more complicated. For example, {{nowrap|<code>Foo<1>(3);</code>}} 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 (Java)|interface]].
* In Java, all types belong to a namespace ([[Java package]]), and there is no such thing as a "global namespace" (even in compact source files where code seemingly does not reside in any class, such code belongs to a final top-level class in the unnamed package), unlike C++ where any code not part of a namespace is part of the global namespace. In Java, the "unnamed package" is not a global namespace, and classes in it cannot be imported by code in named packages.
* Java has a strict global inheritance tree such that all classes (implicitly) extend the [[Top type|top type]], <code>java.lang.Object</code>. C++ does not have any global inheritance tree. It does have a top type <code>std::any</code>, but it is not an inherited type, rather a type-erased runtime object.
* 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.

{| class="wikitable"
! style="width:600px;"| C++
! style="width:600px;"| Java
|-
| <syntaxhighlight lang="cpp">
// Declares class Foo
// Foo is declared exported from the module
export class Foo {
private:
    // Private member variable. It will be initialized
    // to 0, if the constructor would not set it. (from C++11)
    int x = 0;
public:
    // Constructor for Foo; initializes x to 0.
    // If the initializer were omitted, the variable
    // would be initialized to the value that has been
    // given at declaration of x.
    Foo():
        x{0} {}

    // Member function bar()
    nodiscard
    int bar(int i) noexcept {
        return 3 * i + x;
    }
};</syntaxhighlight>
| <syntaxhighlight lang="java">
// Defines class Foo
// Foo is declared public to the package
public class Foo {
    // Member variable, normally declared
    // as private to enforce encapsulation
    // initialized to 0 by default
    private int x;

    // Constructor for Foo
    // no-arg constructor supplied by default
    public Foo() {}

    // Member method bar()
    public int bar(int i) {
        return 3 * i + x;
    }
}</syntaxhighlight>
|-
| <syntaxhighlight lang="cpp">
Foo a;
// declares a to be a Foo object value,
// initialized using the default constructor.

// Another constructor can be used as
Foo a(args);
// or (C++11):
Foo a{args};

// with pointers:
Foo* a = new Foo();
</syntaxhighlight>
| <syntaxhighlight lang="java">
Foo a = new Foo();
// declares a to be a reference to a new Foo object
// initialized using the default constructor

// Another constructor can be used as
Foo a = new Foo(args); </syntaxhighlight>
|-
| <syntaxhighlight lang="cpp">
Foo b = a;
// copies the contents of a to a new Foo object b;
// alternative syntax is "Foo b(a)"</syntaxhighlight>
| <syntaxhighlight lang="java">
// Foo b = a;
// would declare b to be reference to the object pointed to by a
Foo b = a.clone();
// copies the contents of the object pointed to by a 
//     to a new Foo object;
// sets the reference b to point to this new object;
// the Foo class must implement the Cloneable interface
//     for this code to compile
</syntaxhighlight>
|-
| <syntaxhighlight lang="cpp">a.x = 5; // modifies the object a</syntaxhighlight>
| <syntaxhighlight lang="java">a.x = 5; // modifies the object referenced by a</syntaxhighlight>
|-
| <syntaxhighlight lang="cpp">
std::println("{}", b.x);
// outputs 0, because b is
// some object other than a
</syntaxhighlight>
| <syntaxhighlight lang="java">
System.out.println(b.x);
// outputs 0, because b points to
// some object other than a</syntaxhighlight>
|-
| <syntaxhighlight lang="cpp">
Foo* c;
// declares c to be a pointer to a
// Foo object (initially
// undefined; could point anywhere)</syntaxhighlight>
| <syntaxhighlight lang="java">
Foo c;
// declares c to be a reference to a Foo
// object (initially null if c is a class member;
// it is necessary to initialize c before use
// if it is a local variable)</syntaxhighlight>
|-
| <syntaxhighlight lang="cpp">
c = new Foo;
// c is set to the value of the address of the Foo object created by operator new</syntaxhighlight>
| <syntaxhighlight lang="java">
c = new Foo();
// binds c to reference a new Foo object</syntaxhighlight>
|-
| <syntaxhighlight lang="cpp">
Foo& d = *c;
// binds d to reference the same object to which c points</syntaxhighlight>
| <syntaxhighlight lang="java">
Foo d = c;
// binds d to reference the same object as c</syntaxhighlight>
|-
| <syntaxhighlight lang="cpp">
c->x = 5;
// modifies the object pointed to by c</syntaxhighlight>
| <syntaxhighlight lang="java">
c.x = 5;
// modifies the object referenced by c</syntaxhighlight>
|-
| <syntaxhighlight lang="cpp">
d.bar(5); // invokes Foo::bar() for a
c->bar(5); // invokes Foo::bar() for *c
</syntaxhighlight>
| <syntaxhighlight lang="java">
d.bar(5); // invokes Foo.bar() for a
c.bar(5); // invokes Foo.bar() for c
</syntaxhighlight>
|-
| <syntaxhighlight lang="cpp">
std::println("{}", d.x);
// outputs 5, because d references the
// same object to which c points
</syntaxhighlight>
| <syntaxhighlight lang="java">
System.out.println(d.x);
// outputs 5, because d references the
// same object as c</syntaxhighlight>
|-
| 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.
<syntaxhighlight lang="cpp">
// it is not possible to modify the object
// pointed to by a through a
const Foo* a;
</syntaxhighlight>

| The <code>final</code> keyword is similar to the <code>const</code> keyword in C++, but its usage is more limited.{{sfn|Goetz|Peierls|Bloch|Bowbeer|2006|loc=§3.4.1 Final fields|p=48}} 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 <code>final</code>.
<syntaxhighlight lang="java">
// a declaration of a "final" reference:
// it is possible to modify the object, 
// but the reference will constantly point 
// to the first object assigned to it
final Foo a;
</syntaxhighlight>
|-
| <syntaxhighlight lang="cpp">a = new Foo();</syntaxhighlight>
| <syntaxhighlight lang="java">a = new Foo(); // Only in constructor</syntaxhighlight>
|-
| <syntaxhighlight lang="cpp">a->x = 5;
// ILLEGAL</syntaxhighlight>
| <syntaxhighlight lang="java">a.x = 5;
// LEGAL, the object's members can still be modified 
// unless explicitly declared final in the declaring class</syntaxhighlight>
|-
| <syntaxhighlight lang="cpp">Foo* const b = new Foo();
// a declaration of a "const" pointer
// it is possible to modify the object,
// but the pointer will constantly point
// to the object assigned to it here</syntaxhighlight>
| <syntaxhighlight lang="java">final Foo b = new Foo();
// a declaration of a "final" reference</syntaxhighlight>
|-
| <syntaxhighlight lang="cpp">b = new Foo();
// ILLEGAL, it is not allowed to re-bind it</syntaxhighlight>
| <syntaxhighlight lang="java">b = new Foo();
// ILLEGAL, it is not allowed to re-bind it</syntaxhighlight>
|-
| <syntaxhighlight lang="cpp">b->x = 5;
// LEGAL, the object can still be modified</syntaxhighlight>
| <syntaxhighlight lang="java">b.x = 5;
// LEGAL, the object can still be modified</syntaxhighlight>
|}
* C++ supports <code>[[Goto|goto]]</code> statements, which may lead to [[Spaghetti code|spaghetti code]] programming. With the exception of the goto statement (which is very rarely seen in real code and highly discouraged), both Java and C++ have basically the same [[Control flow|control flow]] structures, designed to enforce structured control flow, and relies on [[Control flow#Early exit from loops|break and continue]] statements to provide some <code>goto</code>-like functions. Some commenters point out that these labelled flow control statements break the single point-of-exit property of structured programming.<ref name="Martin">{{cite web|url=http://www.objectmentor.com/resources/articles/javacpp.pdf|title=Java vs. C++: A Critical Comparison|date=January 1997|author=Robert C. Martin|access-date=15 December 2007|archive-url=https://web.archive.org/web/20080511205821/http://www.objectmentor.com/resources/articles/javacpp.pdf|archive-date=11 May 2008|url-status=dead}}</ref>
* C++ provides low-level features which Java mostly lacks (one notable exception being the <code>sun.misc.Unsafe</code> API for direct memory access and manipulation). In C++, pointers can be used to manipulate specific memory locations, a task necessary for writing low-level [[Operating system|operating system]] components. Similarly, many C++ compilers support an [[Inline assembler|inline assembler]].  Assembly language code can be imported to a C/C++ program and vice versa.  This makes C/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. However, since Java 21 with the introduction of the unnamed class, it is possible to write a Java program consisting only of a main function.
* C++ allows a range of implicit conversions between native types (including some narrowing conversions), 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 (<code>if</code>, <code>while</code> and the exit condition in <code>for</code>) in Java and C++ both expect a Boolean expression, code such as <syntaxhighlight lang="cpp" inline>if (a = 5)</syntaxhighlight> 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 <syntaxhighlight lang="cpp" inline>if (a == 5)</syntaxhighlight> 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. <code>a == 5;</code>, 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.<ref>{{cite web|title=Reference Types and Values|url=http://java.sun.com/docs/books/jls/third_edition/html/typesValues.html#4.3|work=The Java Language Specification, Third Edition|access-date=9 December 2010}}</ref><ref>{{cite book |title= Core Java |volume= I |edition= Eighth |last1= Horstmann |first1= Cay |last2= Cornell |first2= Gary |publisher= Sun Microsystems |date= 2008 |isbn= 978-0-13-235476-9 |pages= 140–141 |quote=Some programmers (and unfortunately even some book authors) claim that the Java programming language uses call by reference for objects. However, that is false. Because this is such a common misunderstanding, it is worth examining a counterexample in some detail... This discussion demonstrates that the Java programming language does not use call by reference for objects. Instead ''object references are passed by value''.}}</ref><ref>{{cite book |title= Java for Programmers |last1= Deitel |first1= Paul |last2= Deitel |first2= Harvey |publisher= Prentice Hall |date= 2009 |isbn= 978-0-13-700129-3 |page= 223 |quote= Unlike some other languages, Java does not allow programmers to choose pass-by-value or pass-by-reference—all arguments are passed by value. A method call can pass two types of values to a method—copies of primitive values (e.g., values of type int and double) and copies of references to objects (including references to arrays). Objects themselves cannot be passed to methods.}}</ref>
* 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 (number of bits) 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 (i.e., 64-bit integers for a 64-bit 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 (although only very exotic or old platforms depart from the [[IEEE 754]] standard). Java provides an optional ''strict floating-point model'' ([[Strictfp|strictfp]]) 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 (usually excluding strict rounding rules and raise exceptions on NaN results), but provide compliance options of varied strictness, to allow for some optimizing.<ref>{{cite web |url= https://gcc.gnu.org/wiki/FloatingPointMath |title= Semantics of Floating Point Math in GCC |publisher= GNU Foundation |access-date= 20 April 2013}}</ref><ref>{{cite web |url= http://msdn.microsoft.com/en-us/library/e7s85ffb.aspx |title= Microsoft c++ compiler, /fp (Specify Floating-Point Behavior) |publisher= Microsoft Corporation |access-date=19 March 2013}}</ref> If we label those options from least compliant to most compliant as ''fast'', ''consistent'' (Java's ''strictfp''), ''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++, [[Pointer (computer programming)|pointers]] can be manipulated directly as memory address values. Java references are pointers to objects.<ref>{{cite web |url= http://java.sun.com/docs/books/jls/third_edition/html/typesValues.html#4.3.1 |title= Java Language Specification 4.3.1: Objects |publisher= Sun Microsystems |access-date=9 December 2010}}</ref> 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 Java, memory can be read and written by arbitrary values using the <code>sun.misc.Unsafe</code> API, however it is deprecated and not recommended.
* In C++, pointers can point to functions or member functions ([[Function pointer|function pointer]]s). 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 (even objects with proper destructors can be allocated using <code>new</code> and left undeleted) it provides an effective means of resource management. Shared resources can be managed using <code>std::shared_ptr<T></code>, along with <code>std::weak_ptr<T></code> to break cyclic references. Java supports automatic memory management using [[Garbage collection (computer science)|garbage collection]]{{sfn|Bloch|2018|loc=Chapter §2 Item 8: Avoid finalizers and cleaners|pp=29-33}} which can free unreachable objects even in the presence of cyclic references, but other system resources (files,{{sfn|Bloch|2018|loc=Chapter §2 Item 7: Eliminate obsolete references|pp=123-125}} streams, windows, communication ports, threads, etc.) 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]]. Operator overloading allows for user-defined types to support operators (arithmetic, comparisons, etc.) 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 (although its library uses the addition operator for string concatenation).
* Java features standard [[Application programming interface|application programming interface]] (API) support for [[Reflective programming|reflective programming]] (reflection) and [[Dynamic loading|dynamic loading]] of arbitrary new code.
* C++ supports static and dynamic linking of binaries.
* Java has [[Generic programming#Generics in Java|generics]], which main purpose is to provide type-safe containers. C++ has compile-time [[Generic programming#Templates in C++|templates]], which provide more extensive support for generic programming and metaprogramming. Java has [[Java annotation|annotations]], which allow adding arbitrary custom metadata to classes and metaprogramming via an annotation processing tool.
* Both Java and C++ distinguish between native types (also termed ''fundamental'' or ''built-in'' types) and user-defined types (also termed ''compound'' 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|multiple inheritance]] of arbitrary classes. In Java a class can derive from only one class,{{sfn|Bloch|2018|loc=Foreword|pp=xi-xii}} but a class can implement multiple [[Interface (Java)|interfaces]]{{sfn|Bloch|2018|loc=Chapter §8 Item 8: Favor composition over inheritance|pp=87-92}} (in other words, it supports multiple inheritance of types, but only single inheritance of implementation).
* 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 <code>synchronized</code> keyword in Java provides [[Mutual exclusion|mutex locks]] to support multi-threaded applications.{{sfn|Goetz|Peierls|Bloch|Bowbeer|2006|loc=§2.3.1 Intrinsic locks|pp=25-26}}{{sfn|Bloch|2018|loc=Chapter §11 Item 78: Synchronize access to shared mutable data|pp=126-129}} Java also provides libraries for more advanced multi-threading synchronizing. [[C++11]] has 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 function|virtual function]]s, which means the method to be called is determined by the run-time type of the object (a.k.a. dynamic dispatching). By default, methods in C++ are not virtual (i.e., ''opt-in virtual''). In Java, methods are virtual by default, but can be made non-virtual by using the <code>[[Final (Java)|final]]</code> keyword (i.e., ''opt-out virtual'').
* C and C++ enumerations are primitive types. C enumerations (<code>enum</code>) support implicit conversion to integer types (but not from integer types), while C++ enumerations (<code>enum class</code>) do not. Java enumerations can be {{code|public static enum MyEnum { VALUE_1, VALUE_2 }|java}} and are used like classes. Another way is to make another class that extends <code>java.lang.Enum<E></code>) and may therefore define constructors, fields, and methods as any other class. As of [[C++11]], C++ supports [[C++11#Strongly typed enumerations|strongly-typed enumerations]] which provide more type-safety and explicit specification of the storage type.
* Unary operators {{code|++}} and {{code|--}}: in C++ "The operand shall be a modifiable [[Value (computer science)|lvalue]]. [skipped] The result is the updated operand; it is an lvalue...",<ref>Standard for Programming Language C++ '11, 5.3.2 Increment and decrement [expr.pre.incr].</ref> but in Java "the binary numeric promotion mentioned above may include unboxing conversion and value set conversion. If necessary, value set conversion {and/or [...] boxing conversion} is applied to the sum prior to its being stored in the variable.",<ref>The Java™ Language Specification, Java SE 7 Edition, Chapters 15.14.2, 15.14.3, 15.15.1, 15.15.2, http://docs.oracle.com/javase/specs/</ref> i.e. in Java, after the initialization {{code|1=Integer i = 2; ++i;|2=java}} changes the reference {{code|i}} by assigning new object, while in C++ the object is still the same.

=== Resource management ===
* Java offers automatic [[Garbage collection (computer science)|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 pointer|smart pointer]]s. 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,{{sfn|Bloch|2018|loc=Chapter §2 Item 8: Avoid finalizers and cleaners|pp=29-33}} while C++ relies mainly on the Resource Acquisition Is Initialization (RAII) 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 (except in virtual machines that use [[Escape analysis|escape analysis]] to convert heap allocations to stack allocations).
** C++ has destructors,{{sfn|Bloch|2018|loc=Chapter §2 Item 8: Avoid finalizers and cleaners|pp=29-33}} while Java has [[Finalizer|finalizer]]s.{{sfn|Bloch|2018|loc=Chapter §2 Item 8: Avoid finalizers and cleaners|pp=29-33}} Both are invoked before an object's deallocation, but they differ significantly. A C++ object's destructor must be invoked implicitly (in the case of stack-bound variables) or explicitly to deallocate an object. The destructor executes [[Synchronization|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. Destructors in C++ is the normal way of getting back the resources associated with an object, and is a needed counterpart to constructors.{{sfn|Bloch|2018|loc=Chapter §2 Item 8: Avoid finalizers and cleaners|pp=29-33}} In Java, object deallocation is implicitly handled by the garbage collector. A Java object's finalizer is invoked [[Asynchrony (computer programming)|asynchronously]] 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.{{sfn|Bloch|2018|loc=Chapter §2 Item 8: Avoid finalizers and cleaners|pp=29-33}} Direct usages of finalizers are usually not advised, as they are unpredictable, usually dangerous, and most of the time unneeded.{{sfn|Bloch|2018|loc=Chapter §2 Item 8: Avoid finalizers and cleaners|pp=29-33}} One has to be cautious not to think of finalizers as C++ destructors.{{sfn|Bloch|2018|loc=Chapter §2 Item 8: Avoid finalizers and cleaners|pp=29-33}} Rather, the try-with-resources or try-finally block achieves a more similar purpose as the destructor.{{sfn|Bloch|2018|loc=Chapter §2 Item 8: Avoid finalizers and cleaners|pp=29-33}} One problem with finalizers or cleaners is that it is not guaranteed that they will run immediately.{{sfn|Bloch|2018|loc=Chapter §2 Item 8: Avoid finalizers and cleaners|pp=29-33}} Hence, a finalizer should never be used for tasks that are time-critical.{{sfn|Bloch|2018|loc=Chapter §2 Item 8: Avoid finalizers and cleaners|pp=29-33}} Additionally, finalizers come with severe performance penalties and significantly increase the time it takes for objects to be deallocated, so their use is discouraged and deprecated in Java 9. 
** 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. Alternatively, the try-with-resources construct, which was introduced in Java 7, should be used in preference to try-finally construct. {{sfn|Bloch|2018|loc=Chapter §2 Item 9: Prefer try-with-resources to try-finally|pp=34-36}} The try-with-resources construct is more concise and readable.{{sfn|Bloch|2018|loc=Chapter §2 Item 9: Prefer try-with-resources to try-finally|pp=34-36}} It also provide more helpful diagnostic information, since suppressed exception are not discarded, and will be printed in the stack trace with information saying that they were suppressed.{{sfn|Bloch|2018|loc=Chapter §2 Item 9: Prefer try-with-resources to try-finally|pp=34-36}}
** In C++, it is possible to have a [[Dangling pointer|dangling pointer]], a stale [[Reference (computer science)|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 (deallocated), and results in a [[Memory leak|memory leak]]. In contrast, in Java an object will not be deallocated by the garbage collector ''until'' it becomes unreachable (by the user program). (''[[Weak reference]]s'' are supported, which work with the Java garbage collector to allow for different ''strengths'' of reachability.) Garbage collection in Java prevents many memory leaks, but leaks are still possible under some circumstances.<ref>{{cite web|url=http://www-128.ibm.com/developerworks/rational/library/05/0816_GuptaPalanki/ |title=Java memory leaks – Catch me if you can |author1=Satish Chandra Gupta |author2=Rajeev Palanki |publisher=IBM DeveloperWorks |date=16 August 2005 |access-date=2015-04-02|archive-url=https://web.archive.org/web/20120722095536/http://www.ibm.com/developerworks/rational/library/05/0816_GuptaPalanki/ |archive-date=2012-07-22}}</ref><ref>[https://web.archive.org/web/20140205030750/http://www.openlogic.com/wazi/bid/188158 How to Fix Memory Leaks in Java] by Veljko Krunic (10 Mar 2009)</ref><ref>[https://stackoverflow.com/questions/6470651/creating-a-memory-leak-with-java Creating a memory leak with Java] on stackoverflow.com</ref> The automatic garbage collector may give the false impression that in Java one does not need to think about memory management.{{sfn|Bloch|2018|loc=Chapter §2 Item 7: Eliminate obsolete references|pp=123-125}} However this is not quite true.{{sfn|Bloch|2018|loc=Chapter §2 Item 7: Eliminate obsolete references|pp=123-125}} Loosely speaking, this is because a program can have "memory leaks", more formally known as "unintentional object retentions".{{sfn|Bloch|2018|loc=Chapter §2 Item 7: Eliminate obsolete references|pp=123-125}} An example of a memory leak that may occur is for a program that has been written without any logical errors, except that it did not eliminate obsolete references.{{sfn|Bloch|2018|loc=Chapter §2 Item 7: Eliminate obsolete references|pp=123-125}} This results in higher use of garbage collector activity, higher [[Memory footprint|memory footprint]].{{sfn|Bloch|2018|loc=Chapter §2 Item 7: Eliminate obsolete references|pp=123-125}} In extreme circumstances, this problem can lead to an <code>java.lang.OutOfMemoryError</code>, but this rarely happens. 
{{sfn|Bloch|2018|loc=Chapter §2 Item 7: Eliminate obsolete references|pp=123-125}} The solution to this is to null out object references. {{sfn|Bloch|2018|loc=Chapter §2 Item 7: Eliminate obsolete references|pp=123-125}} A second common reason for memory leak is the use of cache that has become no longer relevant. The solution to memory leaks due to using old cache is to represent the cache using a <code>java.util.WeakHashMap<K, V></code>.

=== Libraries ===
* C++ provides [[Cross-platform|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]], or since Java 21, the Foreign Function and Memory API, which allow for allocating and managing memory outside of the Java Virtual Machine, as well as calling native (i.e. C/C++) functions.
* The C++ standard library is designed to be minimalistic, providing only a standardised set of general use features, while the [[Java Class Library]] and [[Java Platform Module System]] (the Java standard library) is much more extensive, providing a much larger comprehensive standardised set of features, such as graphics, UI creation, and more.

=== Runtime ===
{| class="wikitable"
! style="width:50%;"| C++
! style="width:50%;"| Java
|-
| C++ is compiled directly to [[Machine code|machine code]] which is then executed directly by the [[Central processing unit|central processing unit]]. 
| Java is compiled to byte-code which the [[Java virtual machine]] (JVM) then [[Interpreter (computing)|interprets]] at runtime. Actual Java implementations do [[Just-in-time compilation|just-in-time compilation]] to native machine code.
|-
|}
* Due to its unconstrained expressiveness, low level C++ language features (e.g. unchecked array access, raw pointers, [[Type punning|type punning]]) cannot be reliably checked at compile-time or without overhead at run-time. Related programming errors can lead to low-level [[Buffer overflow|buffer overflow]]s and [[Segmentation fault|segmentation fault]]s. The [[Standard Template Library]] provides higher-level RAII abstractions (like vector, list and map) to help avoid such errors. In Java, low level errors either cannot occur or are detected by the [[Java virtual machine]] (JVM) and reported to the application in the form of an [[Exception handling|exception]].
* The Java language requires specific behavior in the case of an out-of-bounds array access, which generally requires [[Bounds checking|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 <code>std::vector<T></code>, however, offer optional bounds checking. In summary, Java arrays (<code>T[]</code>) are "usually safe; slightly constrained; often have overhead" while C++ native arrays "have optional overhead; are slightly unconstrained; are possibly unsafe." Java collections like <code>java.util.ArrayList<T></code> can throw exceptions like <code>java.lang.IndexOutOfBoundsException</code>.

=== Templates vs. generics ===
Both C++ and Java provide facilities for [[Generic programming|generic programming]], templates and [[Generics in Java|generics]], respectively. Although they were created to solve similar kinds of problems, and have similar syntax, they are quite different.

:{| class="wikitable"
! C++ Templates
! Java Generics
|-
| Classes, functions, aliases<ref>{{cite web|website=cppreference.com| url=http://en.cppreference.com/w/cpp/language/type_alias| title=Type alias, alias template| accessdate=4 October 2022}}</ref> and variables<ref>{{cite web|url=http://en.cppreference.com/w/cpp/language/variable_template |website=cppreference.com |title=Variable template |accessdate=4 October 2022}}</ref> can be templated.
| Classes and methods can be genericized.
|-
| Parameters can be variadic, of any type, integral value, character literal, or a class template.
| Parameters can be any reference type, including boxed primitive types (i.e. <code>java.lang.Integer</code>, <code>java.lang.Boolean</code>, etc.).
|-
| Separate instantiations of the class or function will be generated for each parameter-set when compiled. For class templates, only the member functions that are used will be instantiated.
| One version of the class or function is compiled, works for all type parameters (via type-erasure).
|-
| Objects of a class template instantiated with different parameters will have different types at run time (i.e., distinct template instantiations are distinct classes).
| Type parameters are erased when compiled; objects of a class with different type parameters are the same type at run time. It causes a different constructor. Because of this type erasure, it is not possible to overload methods using different instantiations of the generic class. 
|-
| Implementation of the class or function template must be visible within a translation unit in order to use it. This usually implies having the definitions in the header files or included in the header file. As of [[C++11]], it is possible to use [[C++11#Extern template|extern templates]] to separate compiling of some instantiations.
| Signature of the class or function from a compiled class file is sufficient to use it.
|-
| Templates can be specialized—a separate implementation could be provided for a particular template parameter.
| Generics cannot be specialized.
|-
| Template parameters can have [[Default argument|default argument]]s. Pre-[[C++11]], this was allowed only for template classes, not functions.
| Generic type parameters cannot have default arguments.
|-
| Wildcards unsupported. Instead, return types are often available as nested [[Typedef|typedef]]s. (Also, [[C++11]] added keyword <code>auto</code>, which acts as a wildcard for any type that can be determined at compile time.) Note that [[C++20]] introduces <code>concept</code> which can represent type restrictions with <code>auto</code>, similar to wildcards.
| Wildcards supported as type parameter.
|-
| Bounding of type parameters and enforcement of relationships between type parameters effectively possible through metaprogramming<ref>[http://www.boost.org/libs/type_traits/doc/html/boost_typetraits/reference.html Boost type traits library]</ref>, or since C++20, directly via <code>std::derived_from<A, B></code> and other [[Concepts (C++)|concepts]]
| Supports bounding of type parameters with <code>A extends B</code> and <code>A super B</code> for upper and lower bounds, respectively; allows enforcement of relationships between type parameters.
|-
| Allows instantiation of an object with the type of the parameter type.
| Precludes instantiation of an object with the type of the parameter type (except via reflection).
|-
| Type parameter of class template can be used for static methods and variables.
| Type parameter of generic class cannot be used for static methods and variables.
|-
| [[Static variable]]s unshared between classes and functions of different type parameters.
| Static variables shared between instances of classes of different type parameters.
|-
| Class and function templates do not necessarily enforce type relations for type parameters in their declaration. Use of an incorrect type parameter results in compiling failure, often generating an error message within the template code rather than in the user's code that invokes it. Proper use of templated classes and functions is dependent on proper documentation. Metaprogramming provides these features at the cost of added effort. Since C++20, [[Concepts (C++)|concepts]] can be used to provide these features.
| Generic classes and functions can enforce type relationships for type parameters in their declaration. Use of an incorrect type parameter results in a type error within the code that uses it. Operations on parametrized types in generic code are only allowed in ways that can be guaranteed to be safe by the declaration. This results in greater type safety at the cost of flexibility.
|-
| Templates are Turing-complete (see [[Template metaprogramming|template metaprogramming]]).
| Generics are also Turing-complete<ref>[https://arxiv.org/abs/1605.05274 Java Generics Are Turing Complete]</ref>
|}

=== Miscellaneous ===
* Java and C++ use different means to divide code into multiple source files. 
** Java uses a [[Java package|package system]] that dictates the file name and path for all program definitions. Its compiler imports the executable class files. 
** Prior to [[C++20]], C++ used a header file [[Source code|source code]] inclusion system to share declarations between source files. Since C++20, however, modules were introduced offering similar functionality to Java packages. All symbols marked <code>export</code> are accessible after importing a module.
** Since [[C++23]], the C++ standard library can now be imported as a module.
* The term "[[Modular programming|module]]" refers to different things. In Java, a [[Java package#Modules|module]] is used to group several packages together, meanwhile in C++ a module represents a single [[Translation unit|translation unit]] that is declared as a module.
** <code>import</code> in C++ imports a module by linking it at compilation, however in C++, modules do not dictate the namespace which a symbol belongs to. Meanwhile, <code>import</code> in Java is used to alias classes to avoid fully qualifying them (similar to <code>using</code> in C++), and does not "import" definitions during compiilation. This is because all classes are handled as needed during runtime by the [[Java class loader]] on demand, and can be invoked even without "importing", simply by fully qualifying the class.
* A Java source file must match the namespace which of the public class it declares (it may be named anything if there are no public classes), and the package it belongs to must match the path it is located in. A package may only declare at most one public class (but may have multiple non-public classes).
* A C++ source file (whether a header or module) may have any arbitrary name, and may contain as many classes as the programmer desires. Modules have no requirement to match the path of its location.
* Compiled Java code files are generally smaller than code files in C++ as [[Java bytecode]] is usually more compact than native [[Machine code|machine code]] and Java programs are never statically linked.
* C++ compiling features an added textual [[Preprocessor|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++ (pre-[[C++11]]) does not specify whether or not these operators truncate to zero or "truncate to negative 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 (where a and b are integer types) that <code>(a/b)*b + (a%b) == a</code> for all a and b (b != 0). 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 (int is 32-bit, long is 64-bit), while in C++ the size of integers and pointers is compiler and [[Application binary interface|application binary interface]] (ABI) 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.

An example comparing C++ and Java exists in [[Wikibooks]].

== Performance ==

In addition to running a compiled Java program, computers running Java applications generally must also run the [[Java virtual machine]] (JVM), while compiled C++ programs can be run without external applications. Early versions of Java were significantly outperformed by statically compiled languages such as C++. This is because the program statements of these two closely related languages may compile to a few machine instructions with C++, while compiling into several byte codes involving several machine instructions each when interpreted by a JVM. For example:
{| class="wikitable"
! Java/C++ statement
! C++ generated code (x86)
! Java generated byte code
|-
| {{code|a[i]++;}}
| {{sxhl|2=nasm|mov edx,[ebp+4h]
mov eax,[ebp+1Ch]
inc dword ptr [edx+eax*4]}}
| {{pre|aload_1
iload_2
dup2
iaload
iconst_1
iadd
iastore}}
|}

Since performance optimization is a very complex issue, it is very difficult to quantify the performance difference between C++ and Java in general terms, and most benchmarks are unreliable and biased. Given the very different natures of the languages, definitive qualitative differences are also difficult to draw. In a nutshell, there are inherent inefficiencies and hard limits on optimizing in Java, given that it heavily relies on flexible high-level abstractions, however, the use of a powerful JIT compiler (as in modern JVM implementations) can mitigate some issues. In any case, if the inefficiencies of Java are too great, compiled C or C++ code can be called from Java via the JNI.

Some inefficiencies that are inherent to the Java language include, mainly:

* 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 <code>[[Security of the Java software platform#The sun.misc.Unsafe class|sun.misc.Unsafe]]</code> 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 (although most native compilers for C++ will do the same when range-checks are optionally used).
* Lack of access to low-level details prevents the developer from improving the program where the compiler is unable to do so.<ref>{{cite journal |first =Nathan |last= Clark |author2=Amir Hormati |author3=Sami Yehia |author4=Scott Mahlke
 |title= Liquid SIMD: Abstracting SIMD hardware using lightweight dynamic mapping |journal= Hpca'07 |pages=216–227 |year= 2007}}</ref>
* The mandatory use of reference-semantics for all user-defined types in Java can introduce large amounts of superfluous memory indirections (or jumps) (unless elided by the JIT compiler) which can lead to frequent cache misses (a.k.a. [[Thrashing (computer science)|cache thrashing]]). Furthermore, cache-optimization, usually via cache-aware or [[Cache-oblivious algorithm|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 (by neither the programmer nor the JIT compiler).
* [[Garbage collection (computer science)|Garbage collection]],<ref name="hundt2011">{{cite web| last=Hundt |first=Robert  |title=Loop Recognition in C++/Java/Go/Scala |publisher=Scala Days 2011 |date=2011-04-27|location=Stanford, California |access-date=2012-11-17 |url=https://days2011.scala-lang.org/sites/days2011/files/ws3-1-Hundt.pdf |archive-url=https://ghostarchive.org/archive/20221009/https://days2011.scala-lang.org/sites/days2011/files/ws3-1-Hundt.pdf |archive-date=2022-10-09 |url-status=live |quote=Java shows a large GC component, but a good code performance. [...] We find that in regards to performance, C++ wins out by a large margin. [...] The Java version was probably the simplest to implement, but the hardest to analyze for performance. Specifically the effects around garbage collection were complicated and very hard to tune; 318&nbsp;kB}}</ref> as this form of automatic memory management introduces memory overhead.<ref name="HertzBerger2005">{{cite web |url=http://people.cs.umass.edu/~emery/pubs/gcvsmalloc.pdf |title=Quantifying the Performance of Garbage Collection vs. Explicit Memory Management |author=Matthew Hertz, Emery D. Berger |publisher=OOPSLA 2005 |date=2005 |access-date=2015-03-15 |quote=In particular, when garbage collection has five times as much memory as required, its runtime performance matches or slightly exceeds that of explicit memory management. However, garbage collection's performance degrades substantially when it must use smaller heaps. With three times as much memory, it runs 17% slower on average, and with twice as much memory, it runs 70% slower. |archive-url=https://web.archive.org/web/20170706100244/https://people.cs.umass.edu/~emery/pubs/gcvsmalloc.pdf |archive-date=6 July 2017 |url-status=dead }}</ref>

However, there are a number of benefits to Java's design, some realized, some only theorized:

* Java [[Garbage collection (computer science)|garbage collection]] may have better cache coherence than the usual use of <code>std::malloc</code>/<code>new</code> for memory allocation. Nevertheless, arguments exist{{Weasel inline|date=March 2012}} 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.<ref>{{cite book |first= Andrei |last= Alexandrescu |title= Modern C++ Design: Generic Programming and Design Patterns Applied. Chapter 4 |editor= Addison-Wesley |pages=77–96 |year= 2001 |isbn= 978-0-201-70431-0}}</ref><ref>{{cite web |url= http://www.boost.org/doc/libs/release/libs/pool/ |title= Boost Pool library |publisher= Boost |access-date=19 April 2013}}</ref>
* 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 (C, C++, etc.) compilers generate multiple code paths to employ the full computational abilities of the given system.<ref>[https://web.archive.org/web/20200929080449/https://www.slac.stanford.edu/comp/unix/.../icc/.../optaps_dsp_qax.htm Targeting IA-32 Architecture Processors for Run-time Performance Checking]</ref> 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.<ref>{{Cite web |url=http://www.azulsystems.com/blog/cliff/2011-04-04-fixing-the-inlining-problem |title=Fixing The Inlining "Problem" by Dr. Cliff Click {{!}}Azul Systems: Blogs |access-date=23 September 2011 |archive-date=7 September 2011 |archive-url=https://web.archive.org/web/20110907092432/http://www.azulsystems.com/blog/cliff/2011-04-04-fixing-the-inlining-problem |url-status=dead }}</ref> 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,{{sfn|Bloch|2018|loc=Chapter §11 Item 78: Synchronize access to shared mutable data|pp=126-129}} so the JIT compiler can potentially, via escape analysis, elide locks,<ref>[http://java.sun.com/performance/reference/whitepapers/6_performance.html#2.1.2 Oracle Technology Network for Java Developers]</ref> significantly improve the performance of naive multi-threaded code.

Also, some performance problems occur in C++:

* Allowing pointers to point to any address can make optimizing difficult due to the possibility of [[Pointer aliasing|pointer aliasing]].
* Since the code generated from various instantiations of the same class template in C++ is not shared (as with type-erased generics in Java), excessive use of templates may lead to significant increase of the executable code size ([[Code bloat|code bloat]]). 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 ===
The C++ language is defined by ''ISO/IEC 14882'', an [[Organization:International Organization for Standardization|ISO]] standard, which is published by the ''ISO/IEC JTC1/SC22/WG21'' committee. C++ typically releases on a three-year cycle.<ref>{{Cite web|title=Draft FAQ: Why does the C++ standard ship every three years?|url=https://herbsutter.com/2019/07/13/draft-faq-why-does-the-c-standard-ship-every-three-years/|publisher=herbsutter.com|author=Herb Sutter|website=herbsutter.com|date=13 July 2019}}</ref>

The C++ language evolves via an open steering committee called the C++ Standards Committee. The committee is composed of the creator of C++ [[Biography:Bjarne Stroustrup|Bjarne Stroustrup]], the convener [[Biography:Herb Sutter|Herb Sutter]], and other prominent figures, including many representatives of industries and user-groups (i.e., the stake-holders). Being an open committee, anyone is free to join, participate, and contribute proposals for upcoming releases of the standard and technical specifications. The committee now aims to release a new standard every few years, although in the past strict review processes and discussions have meant longer delays between publication of new standards (1998, 2003, and 2011). 

The Java language is defined by the ''Java Language Specification'',<ref>[http://java.sun.com/docs/books/jls/ The Java Language Specification]</ref> a book which is published by [[Company:Oracle Corporation|Oracle]]. Java typically releases on a semiannual cycle, though traditionally released once every two years.<ref name="6monthsReinhold">{{cite web| title=Moving Java Forward Faster | last=Reinhold | first=Mark | url=https://mreinhold.org/blog/forward-faster | date=2017-09-06 | access-date=2017-09-16}}</ref><ref name="6monthsServerSide">{{cite web| title=Calling 'all aboard' on the six-month Java release train |publisher=theserverside.com | url=http://www.theserverside.com/news/450426185/Calling-all-aboard-on-the-six-month-Java-release-train | date=2017-09-12 | access-date=2017-09-16}}</ref> 

The Java language continuously evolves via a process called the [[Java Community Process]], and the world's programming community is represented by a group of people and organizations - the Java Community members<ref>[http://www.jcp.org/en/participation/members The Java Community Process(SM) Program - Participation - JCP Members]</ref>—which is actively engaged into the enhancement of the language, by sending public requests - the Java Specification Requests - which must pass formal and public reviews before they get integrated into the language.

The lack of a firm standard for Java and the somewhat more volatile nature of its specifications have been a constant source of criticism by stake-holders wanting more stability and conservatism in the addition of new language and library features. In contrast, the C++ committee also receives constant criticism, for the opposite reason, i.e., being too strict and conservative, and taking too long to release new versions.

=== Trademarks ===
"C++" is not a trademark of any company or organization and is not owned by any individual.<ref>[http://www.stroustrup.com/bs_faq.html#revenues Bjarne Stroustrup's FAQ: Do you own C++?]</ref>
"Java" is a trademark of [[Company:Oracle Corporation|Oracle]].<ref>[http://blogs.zdnet.com/BTL/?p=16598 ZDNet: Oracle buys Sun; Now owns Java] {{Webarchive|url=https://web.archive.org/web/20100410145901/http://blogs.zdnet.com/BTL/?p=16598 |date=10 April 2010 }}.</ref>

== References ==
=== Citations ===
{{Reflist}}
=== Sources ===
*{{cite book | title= "Effective Java: Programming Language Guide" |last=Bloch| first=Joshua| publisher=Addison-Wesley | edition=third | isbn=978-0134685991| year=2018}}
*{{cite book
 | last = Goetz
 | first = Brian
 | last2 = Peierls
 | first2 = Tim
 | last3 = Bloch
 | first3 = Joshua
 | last4 = Bowbeer
 | first4 = Joseph
 | last5 = Holmes
 | first5 = David
 | last6 = Lea
 | first6 = Doug
 | year = 2006
 | title = Java Concurrency in Practice
 | publisher = Addison Wesley
 | isbn = 0-321-34960-1
 | url = https://archive.org/details/javaconcurrencyi00goet
 }}




== External links ==
{{wikibooks|C++ Programming|Programming Languages/Comparisons/Java}}
* [https://web.archive.org/web/20180921225953/https://decodediary.com/2018/09/20/difference-between-c-and-java/ Difference Between C++ and Java]
* [http://ineed.coffee/98/object-oriented-memory-management Object Oriented Memory Management: Java vs. C++]
* [https://web.archive.org/web/20020402093228/http://www.ora.com/catalog/javanut/excerpt/index.html Chapter 2:How Java Differs from C], chapter from Java in a Nutshell by David Flanagan
* [https://web.archive.org/web/20070523171523/http://www.fatalmind.com/papers/java_vs_cplusplus/resource.html Java vs. C++ resource management comparison] - Comprehensive paper with examples
* [https://web.archive.org/web/20100630201919/http://www.azulsystems.com/blog/cliff-click/2009-09-06-java-vs-c-performanceagain Java vs C performance... again...] - In-depth discussion of performance differences between Java and C/C++
* [http://christianrubiales.com/hyperpoly/?q=java,cpp Hyperpoly - Java and C++ Comparison]

{{C++ programming language}}

{{DEFAULTSORT:Comparison Of Java And C Plus Plus}}
[[Category:Java (programming language)]]
[[Category:C++]]

{{Sourceattribution|Comparison of Java and C++}}