Comparison of Java and C++

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>(3); 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 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, java.lang.Object. C++ does not have any global inheritance tree. It does have a top type std::any, but is a type-erased runtime object rather than an inherited type.
• 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.

// 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()
    int bar(int i) noexcept {
        return 3 * i + x;
    }
};

// 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;
    }
}

Foo a;
// declares a to be a Foo object value,
// initialized using the default constructor.

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

// with pointers:
Foo* a = new Foo();

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);

Foo b = a;
// copies the contents of a to a new Foo object b;
// alternative syntax is "Foo b(a)"

// 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

a.x = 5; // modifies the object a

a.x = 5; // modifies the object referenced by a

std::println("{}", b.x);
// outputs 0, because b is
// some object other than a

System.out.println(b.x);
// outputs 0, because b points to
// some object other than a

Foo* c;
// declares c to be a pointer to a
// Foo object (initially
// undefined; could point anywhere)

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)

c = new Foo;
// c is set to the value of the address of the Foo object created by operator new

c = new Foo();
// binds c to reference a new Foo object

Foo& d = *c;
// binds d to reference the same object to which c points

Foo d = c;
// binds d to reference the same object as c

c->x = 5;
// modifies the object pointed to by c

c.x = 5;
// modifies the object referenced by c

d.bar(5); // invokes Foo::bar() for a
c->bar(5); // invokes Foo::bar() for *c

d.bar(5); // invokes Foo.bar() for a
c.bar(5); // invokes Foo.bar() for c

std::println("{}", d.x);
// outputs 5, because d references the
// same object to which c points

System.out.println(d.x);
// outputs 5, because d references the
// same object as c

// it is not possible to modify the object
// pointed to by a through a
const Foo* a;

// 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;

a = new Foo();

a = new Foo(); // Only in constructor

a->x = 5;
// ILLEGAL

a.x = 5;
// LEGAL, the object's members can still be modified 
// unless explicitly declared final in the declaring class

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

final Foo b = new Foo();
// a declaration of a "final" reference

b = new Foo();
// ILLEGAL, it is not allowed to re-bind it

b = new Foo();
// ILLEGAL, it is not allowed to re-bind it

b->x = 5;
// LEGAL, the object can still be modified

b.x = 5;
// LEGAL, the object can still be modified

• C++ supports goto statements, which may lead to 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 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 mostly lacks (one notable exception being the internal sun.misc.Unsafe 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 components. Similarly, many C++ compilers support an inline assembler, and assembly functions may be linked in C/C++ programs. 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 (if, while and the exit condition in for) in Java and C++ both expect a Boolean expression, code such as if (a = 5) 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 (a == 5) 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. a == 5;, 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 (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) 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. 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++, 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 Java, memory can be read and written by arbitrary values using the sun.misc.Unsafe API, however it is deprecated and not recommended.
• In C++, pointers can point to functions or member functions (function pointers). The equivalent mechanism in Java uses object or interface references.
• Both Java and C++ allow type inference. Java uses the var keyword, while C++ uses the auto keyword (historically, such as back in B and C, auto declared the variable with automatic storage). In C++, if auto is used as a function's parameter type, it denotes an anonymous (unnamed) template, making the parameter generic. If auto is preceded by a concept, it ensures the deduced type satisfies the concept (or halts compilation if not), and if in a context in which auto represents an abbreviated type parameter, constrains the type by that concept.
• 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 new and left undeleted) it provides an effective means of resource management. Shared resources can be managed using std::shared_ptr<T>, along with std::weak_ptr<T> 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 (files, 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. Java allows scope resource management through try-with-resources blocks for types that implement java.lang.AutoCloseable, but unlike C++, the object is not disposed from memory, but only owned resources are disposed by the close() method.
• C++ features user-defined 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 (API) support for reflective programming (reflection) and dynamic loading of arbitrary new code.
• C++ supports static and dynamic linking of binaries.
• Both Java and C++ (since C++26) offer reflection, allowing for a degree of code introspection. Reflection in Java acts primarily at runtime and is primarily behavioral, while reflection in C++ acts at compile-time and produces meta-objects, and is primarily generative.
• Java has generics, which main purpose is to provide type-safe containers. However, Java generics are not reified (act only at compile-time), and are type-erased at runtime. C++ has compile-time templates, which provide more extensive support for generic programming and metaprogramming. C++ templates instantiate a specialization for each type used with them.
• Both Java and C++ offer annotations. Java annotations allow adding arbitrary custom metadata to classes and metaprogramming via an annotation processing tool. C++ offers attributes to indicate compiler-defined metadata, as well as annotations (since C++26) which can user-defined and read at compile time, but not at runtime like in Java.
• 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 of arbitrary classes. In Java a class can derive from only one class, but a class can implement multiple interfaces (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 synchronized keyword in Java provides mutex locks to support multi-threaded applications. 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.
• 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 (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 final keyword (i.e., opt-out virtual).
• C++ features a language-level override keyword to indicate overriding a virtual method. Java does not, but features a @Override annotation to indicate overriding, which issues a compiler error if no existing method is being overriden.
• C and C++ enumerations are primitive types. C enumerations (enum) implicitly convert to integer types (but not from integer types), while C++ enumerations (enum class) are strongly typed and do not implicitly convert. Java enumerations behave like classes and may define constructors and methods.
• Unary operators ++ and --: in C++ "The operand shall be a modifiable lvalue. [skipped] 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 {and/or [...] boxing 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.
• In Java, lambdas are "poly expressions", whose types dependent on context, while in C++, lambdas have a real runtime class which can be accessed with decltype and are part of the language model. Java lambdas depend on the functional interface which they are assigned to.

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 (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 to convert heap allocations to stack allocations).
  • 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 (in the case of stack-bound variables) 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. Destructors in C++ is the normal way of getting back the resources associated with an object, and is a needed counterpart to constructors. In Java, object deallocation is implicitly handled by the garbage collector. A Java object's finalizer is invoked 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. Direct usages of finalizers are usually not advised, as they are unpredictable, usually dangerous, and most of the time unneeded. One has to be cautious not to think of finalizers as C++ destructors. Rather, the try-with-resources or try-finally block achieves a more similar purpose as the destructor. One problem with finalizers or cleaners is that it is not guaranteed that they will run immediately. Hence, a finalizer should never be used for tasks that are time-critical. 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. The try-with-resources construct is more concise and readable. 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.
  • 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 (deallocated), and results in a 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 references 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. The automatic garbage collector may give the false impression that in Java one does not need to think about memory management. However this is not quite true. Loosely speaking, this is because a program can have "memory leaks", more formally known as "unintentional object retentions". 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. This results in higher use of garbage collector activity, higher memory footprint. In extreme circumstances, this problem can lead to an java.lang.OutOfMemoryError, but this rarely happens.

The solution to this is to null out object references. 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 java.util.WeakHashMap.

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, 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 and more comprehensive standardised set of features, such as graphics and UI creation, multimedia, cryptography, XML parsing, SQL management, and more.

Runtime

• Due to its unconstrained expressiveness, low level C++ language features (e.g. unchecked array access, raw pointers, type punning) 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 collection types (like std::vector, std::unordered_map, std::deque) 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.
  • Exceptions are tightly coupled in the Java runtime and language-level operations (including but not limited to division-by-zero, null reference access, invalid casting, and out-of-bounds array access) may throw exceptions, whereas in C++ typically only objects throw (with the exception of the typeid() which may throw a std::bad_typeid exception, new which may throw std::bad_alloc or std::bad_array_new_length, new which may throw std::bad_alloc, or dynamic_cast which may throw std::bad_cast). Furthermore, in C++, exceptions may be "disabled" (such as with -no-exceptions on GCC or Clang, or /Ehsc on MSVC), which will prevent the compiler from generating code for exception handling, and terminate a program with std::terminate() upon a throw statement.
  • Java features checked exceptions, which are exceptions that must be handled in a catch block, and can only be allowed to propagate through functions that explicitly declare them with a throws clause. Any exception which does not extend java.lang.RuntimeException is considered a checked exception. Meanwhile, in C++, the concept of "checked exceptions" does not exist, but functions may be specified not to throw with a noexcept specifier. Until C++17 (though first deprecated in C++11), C++ allowed dynamic exception specifications through a throw clause in the function signature, which like Java throws clauses, allowed functions to specify which types may be thrown.
  • r Java allows only classes which extend java.lang.Throwable to be thrown by a throw statement. In C++, any object, including primitives, may be thrown and caught. Java differentiates between java.lang.Error (representing runtime errors considered unreasonable to catch) and java.lang.Exception (representing possible recoverable errors considered reasonable to catch) while in C++, the usual base exception class is std::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<T>, however, offer optional bounds checking. In summary, Java arrays (T[]) are "usually safe; slightly constrained; often have overhead" while C++ native arrays "have optional overhead; are slightly unconstrained; are possibly unsafe." Java collections like java.util.ArrayList can throw exceptions like java.lang.IndexOutOfBoundsException. C++26 specifies compile-time "bounds hardening" in the standard library, which now define certain undefined behaviors (including out-of-bounds access) to be contract violations.

Templates vs. generics

Both C++ and Java provide facilities for generic programming, templates and generics, respectively. Although they were created to solve similar kinds of problems, and have similar syntax, they are quite different.

C++ Templates	Java Generics
Classes, functions, aliases and variables 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. java.lang.Integer, java.lang.Boolean, 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 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 arguments. 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 typedefs. (Also, C++11 added keyword auto, which acts as a wildcard for any type that can be determined at compile time.) Note that C++20 introduces concept which can represent named type restrictions with auto, while general constraints can be represented with requires clauses, similar to wildcards.	Wildcards supported as type parameter.
Bounding of type parameters possible using concepts (such as std::derived_from<A, B>); otherwise possible using template metaprogramming in prior versions	Supports bounding of type parameters with A extends B and A super B 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 variables 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 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).	Generics are also Turing-complete

Asynchronous/concurrent programming

• Java lacks an asynchronous runtime entirely. Java traditionally relies on thread pools managed by a java.util.concurrent.ExecutorService, which runs on an operating system multi-threading. For non-blocking I/O, Java offers java.nio.
• Java 21 with Project Loom introduces virtual threads (similar to Go's "goroutines" which are analogous to green threads), allowing writing traditional blocking code inside a virtual thread with automatic unmounting and remounting.
• C++20 introduces true coroutines, C++23 introduces generators in the standard library, and C++26 introduces an asynchronous task type in the standard library. C++20 introduces three new keywords (but no async keyword):
  • co_await: suspends execution until resumed, analogous to await in other languages
  • co_yield: suspends execution, returning a value, analogous to yield in other languages' generators
  • co_return: completes execution, returning a value
• C++26 introduces the std::execution library, which is a lazy, composable, zero-overhead framework, while Java's java.util.concurrent.ExecutorService is an eager runtime. Java yields the execution control to the internal task queue, while C++ only starts execution when a receiver connects to a sender and calls start().
  • C++'s std::execution::scheduler<Sch> is an execution engine, analogous to Java's java.util.concurrent.ExecutorService.
  • C++'s std::execution::sender<Snd> is an async pipeline, analogous to Java's java.util.concurrent.CompletableFuture.
  • C++'s std::execution::receiver<Rcv> is a callback/sink, analogous to Java's internal completion handlers/lambdas.
  • Java lacks a true equivalent to C++'s std::execution::task<T, Env>, which represents a unit of asynchronous work, and is a sender that is often used as a coroutine's return type to be co_awaited; Java avoids the need for a task type by using virtual threads, avoiding separating synchronous and asynchronous code entirely.
• Older C++ used std::async() (introduced in C++11), which receives a unit of work (a lambda) and returns a std::future<T> as a receipt, similar to Java's ExecutorService.submit() which returned a java.util.concurrent.Future.

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.
  • Prior to C++20, C++ used a header file 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 export are accessible after importing a module.
  • Since C++23, the C++ standard library can now be imported as a module.
• The term "module" refers to different things. In Java, a module is used to group several packages together, meanwhile in C++ a module represents a single translation unit that is declared as a module.
  • import in C++ imports a module by loading its BMI (built module interface) at compilation, however in C++, modules do not dictate the namespace which a symbol belongs to. Meanwhile, import in Java is used to alias classes to avoid fully qualifying them (equivalent to using 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 used even without an import statement 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 class files are generally smaller than object files in C++ as Java bytecode is usually more compact than native machine code^{[further explanation needed]}, and Java does not perform static linking.
• 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. Prior to C++11, C++ did 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 (a / b) * b + (a % b) == a for all a and b (b non-zero). 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 fixed in Java (for example int is 32-bit, long is 64-bit), while in C++ the size of integers and pointers is compiler and 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. However, C/C++ also have fixed width sizes (such as int32_t for signed 32-bit integers, uint64_t for unsigned 64-bit integers, etc.)

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

Language specification

The C++ language is defined by ISO/IEC 14882, an ISO standard, which is published by the ISO/IEC JTC1/SC22/WG21 committee. C++ typically releases on a three-year cycle.

The C++ language evolves via an open steering committee called the C++ Standards Committee. The committee is composed of the creator of C++ Bjarne Stroustrup, the convener 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, a book which is published by Oracle. Java typically releases on a semiannual cycle, though traditionally released once every two years.

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—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.^{[citation needed]}

Trademarks

"C++" is not a trademark of any company or organization and is not owned by any individual. "Java" is a trademark of Oracle.

Citations

Sources

• Bloch, Joshua (2018). "Effective Java: Programming Language Guide" (third ed.). Addison-Wesley. ISBN 978-0134685991.
• Goetz, Brian; Peierls, Tim; Bloch, Joshua; Bowbeer, Joseph; Holmes, David; Lea, Doug (2006). Java Concurrency in Practice. Addison Wesley. ISBN 0-321-34960-1.