C++.CodeCompared.To/Java

No headers, no includes for anything in java.lang, and no return value: main is void, and a status code comes from System.exit when you want one. The other visible absence is std::endl; println adds the newline, and System.out flushes on newline by default, so the flush-versus-newline distinction that matters in a C++ loop does not arise here.

The practical consequences run in both directions. Startup is slower and the first thousand iterations of a loop are much slower, which is why a Java command-line tool feels sluggish and a Java server does not. But the JIT compiles against what is actually happening — it inlines the one implementation an interface really has, and deoptimizes if a second one shows up — which a static compiler cannot do. That is the real answer to "which is faster": for a short program, C++, and for a long-running one, it depends on the code.

That removes a whole category of C++ work: no header/implementation split, no include guards, no forward declarations, no "undeclared identifier" versus "undefined reference" distinction to explain, and no compile-time cost from a header being re-parsed for every translation unit. What replaces it is the classpath — a list of directories and jar files the compiler and the JVM search for classes — and one public class per file, named after the file.

🚨 Do not look for a replacement — there is not one. finalize() existed, was unreliable for twenty years, and was removed. Cleaner and phantom references exist for native memory and are not a lifetime mechanism. What replaces RAII is try-with-resources, in the Resources section, and the difference is that the obligation moves from the type to every call site: in C++ you cannot forget to close a file, and in Java you can.

The layout difference is the one that shows up in a profiler. A std::vector<Point> is one contiguous block that a cache line reads three points out of; an ArrayList<Point> is an array of references pointing at objects scattered wherever the allocator put them. Escape analysis lets the JIT put some short-lived objects on the stack, and Project Valhalla is adding real value types — but as of Java 25 the rule stands, and it is why numeric code stores int[] rather than List<Integer>.

So the collector buys you no leaks from cycles, no use-after-free, no double-free, and no weak_ptr to remember. What it costs is control: you cannot say when memory is reclaimed, a pause can happen at an inconvenient moment (modern collectors like ZGC keep those under a millisecond, which is a different world from the old ones), and the heap is several times larger than the live data. The C++ answer — unique_ptr everywhere and a cycle broken by hand — is more work and more predictable, which is exactly the trade.

Every habit built on value semantics has to be re-examined. A method that takes a List can modify the caller's list, and the signature cannot say otherwise — there is no const anywhere in the language. The defensive moves are copying at the boundary (new ArrayList<>(other)), handing out List.copyOf(other), which is genuinely immutable, or designing with immutable types so the question does not arise. Only the eight primitives are copied on assignment.

There is no way to express "I will not modify this argument" in a Java signature, and that absence shapes the standard library: List.of(...), Map.of(...) and List.copyOf(...) return collections that throw on any modification, because immutability had to be moved into the object when it could not live in the type. Read a Java API defensively — if a method's documentation does not say it leaves your collection alone, it may not.

Two obligations follow. Call .equals() for value comparison, always. And when you write a class that has a notion of equality, override equals and hashCode together — a HashMap uses hashCode to find the bucket and equals to search it, so overriding one without the other produces an object that cannot find itself in a map it was just put into. Records, later on this page, generate both for you and are the reason to prefer them.

The real difference is that Java has null underneath everything and cannot get rid of it: any reference may be null, there is no non-nullable type, and NullPointerException is the most common failure in production Java. Modern practice is Optional for return values (never for fields or parameters), Objects.requireNonNull at boundaries, and annotations that a static analyzer checks. Helpful NullPointerException messages, on by default since Java 15, at least now name which reference was null.

Two differences that matter in practice. Signed overflow is defined to wrap in Java, where in C++ it is undefined behavior the optimizer may assume cannot happen — so the Java answer is merely wrong rather than dangerous. And there are no unsigned types at all: use >>> for a logical right shift, and the Integer.toUnsignedString and Long.compareUnsigned family when you have to treat a value as unsigned. A char is 16 bits because Java predates the discovery that Unicode needed more than that.

🚨 The last two lines are the trap, and it is worse than it looks: Integer values from −128 to 127 are cached and shared, so a == b is true for small numbers and false for large ones. Code that tests boxed integers with == passes every test written with small values. For arithmetic-heavy work use primitive arrays (int[]) and IntStream, which avoid boxing entirely; Project Valhalla is the long-term fix.

The check costs something and the JIT removes most of it — it proves the index is in range for a counted loop and drops the test. What you get for the rest is that a Java program cannot corrupt its own memory: no buffer overruns, no dangling pointers, no undefined behavior. That single property is why Java took the industry it took, and it is the thing a C++ programmer is genuinely being handed in exchange for everything else on this page.

Immutability buys real things: a string can be shared between threads with no synchronization, used as a map key safely, and cached — which is why literals are interned. Two encoding notes for a C++ reader: a Java string is UTF-16 internally (compacted to Latin-1 when it fits), so length() counts code units rather than characters and an emoji counts as two, while std::string::size() counts bytes. Neither counts characters; they are wrong in different ways.

The important difference is when the format string is checked: std::format parses it at compile time, so a mismatched placeholder fails the build, while String.format throws at run time. Java 21 added string templates as a preview and then withdrew them, so as of Java 25 there is still no interpolation — concatenation with + is idiomatic and the compiler turns it into efficient code.

There is no operator[], so element access is get and set — a consequence of having no operator overloading at all. LinkedList exists and is almost always the wrong choice; ArrayList is the default the way std::vector is. And unlike a std::vector, adding to an ArrayList cannot invalidate a reference to an element, because the elements are separate objects and only the array of pointers is reallocated.

One trap goes away and another arrives. get on a missing key returns null rather than inserting a default the way std::map::operator[] does — a genuine improvement — but that null then flows into your code, so getOrDefault(key, 0) is usually what you want. Going the other way, merge(key, 1, Integer::sum) and computeIfAbsent do in one call what C++ needs a find-then-insert dance for.

Two Java specifics. mapToInt switches to a primitive stream and avoids boxing every intermediate value, which is worth doing whenever the elements are numbers. And a stream is single-use: consuming it leaves it spent, where a C++ view can be iterated again. .parallel() is the one thing with no ranges equivalent — it spreads the work over the common pool, which is free to write and easy to misuse on work that is too small.

Three consequences. There is no object slicing, because objects are never copied by value. There is no need for a virtual destructor, because there are no destructors. And @Override is not required but should always be written — it makes the compiler check you really are overriding something, which catches a base-class signature change, and it is the same discipline as C++'s override. The cost of virtual-by-default is paid by the JIT, which inlines a call site with only one implementation and undoes that if a second class turns up.

Multiple inheritance of state is what Java refuses, which is what removes the diamond problem and virtual inheritance along with it — an interface has no fields. That is a real loss for a C++ programmer who uses mixins and the curiously recurring template pattern; what replaces them is composition, default methods, and generics with bounded type parameters. Records and sealed interfaces, later on this page, cover much of what an abstract base class was used for.

The one exception is + on strings, which is built into the language rather than overloadable. This is a deliberate design choice rather than an omission — no operator on a Java expression can be arbitrary user code, so reading a + b never requires knowing the types — and it is the trade a C++ programmer feels most in numeric code, where BigDecimal arithmetic becomes a.multiply(b).add(c). Note equals takes Object and must be paired with hashCode.

The distinction worth knowing about nested classes is one C++ does not have: a nested class declared static is what a C++ nested class is, while a non-static inner class holds a hidden reference to an instance of its enclosing class. That hidden reference is a real memory leak in long-lived code, so the rule of thumb is to write static class unless you specifically want the enclosing instance. Static initialization also has a defined order here, so the static initialization order fiasco does not exist.

Erasure is why several things a C++ programmer reaches for are simply unavailable: no new Element[10], no instanceof List<String>, no specialization for a particular type, no compile-time computation, and no primitive type arguments. What it buys is that generic code compiles once, produces no code bloat, and interoperates with pre-generics code. Passing Class<Element> as an argument is the standard workaround when you genuinely need the type at run time.

This is what C++20 concepts added, and Java has had it since generics arrived. The error messages are the visible payoff — a violated bound names the constraint rather than producing a page of template instantiation backtrace. The cost is expressiveness: a bound can only say "is a subtype of", where a C++ concept can require an operation, so there is no way to say "any type with a +". Wildcards (List<? extends Number>) cover variance and are the part everyone finds confusing.

C++ tried something adjacent with exception specifications, deprecated them, and kept only noexcept. Java kept its version and the profession has argued about it ever since: it genuinely prevents an unhandled failure mode, and it genuinely produces catch (Exception e) { } blocks written to silence the compiler. Extending RuntimeException instead makes an exception unchecked, which is what most modern libraries do, and what lambdas force — a checked exception cannot escape a standard functional interface.

The genuinely useful addition is the stack trace: every Java exception captures the call stack when it is constructed, with method names and line numbers, and that is most of the difference between debugging a Java production failure and a C++ one. It is not free — filling in the trace is the expensive part of throwing — which is why exceptions are not used for control flow, and why a hot path that throws should reuse a preallocated exception or, better, not throw. Multi-catch with | has no C++ equivalent.

🚨 That shift is the practical cost of losing destructors, and it is worth being blunt about: a leaked file handle in Java is a code review problem rather than an impossible one. Static analysis and the compiler warning for an unclosed AutoCloseable help. The compensating advantages are real too — resources are closed in reverse order, an exception thrown by close() is suppressed rather than replacing the original (getSuppressed() retrieves it), and there is no equivalent of a destructor throwing during unwinding and terminating the program.

This is one of the largest simplifications on the page, and its cost is the one from the References section: since assignment never copies, a class that wants value semantics has to provide them explicitly — a copy constructor you call by name, or a clone() that is widely regarded as a design mistake. The usual answer is to make the class immutable, at which point sharing is safe and copying is pointless, which is why so much modern Java is written that way.

Java's memory model was the first in a mainstream language and C++11 followed it, so the concepts line up: volatile in Java is roughly std::atomic with sequential consistency (it is not C++'s volatile, which means something else entirely), and java.util.concurrent.atomic matches <atomic>. The important difference is what happens when you get it wrong: a data race in Java produces a stale or torn value, while in C++ it is undefined behavior. Prefer ExecutorService and CompletableFuture over raw threads.

The consequence is that blocking stops being expensive, so the whole async style — futures, callbacks, colored functions, an event loop you must never block — becomes unnecessary for input-and-output-bound work. Write the straightforward blocking code and run it on a virtual thread. C++'s nearest equivalent is a coroutine framework, and the standard library ships coroutines with no scheduler, so every project picks a third-party one.

This is the closest Java gets to a C++ aggregate, and for a C++ programmer it is the feature most worth adopting immediately: reach for a record wherever you would write a struct. A compact constructor validates or normalizes arguments without restating them. The limits are that a record is final, cannot extend anything, and cannot have non-final fields — which is the point, because those constraints are what make the generated methods correct.

Sealed interfaces plus records plus switch patterns are Java's answer to std::variant and std::visit, and they are considerably more pleasant to read: no if constexpr, no decay_t, no visitor lambda. Patterns also destructure — case Rect(double width, double height) -> width * height binds the components directly — and take guards with when. For a C++ programmer used to hand-rolled visitors, this is the second feature worth adopting on sight.

That restriction removes the dangling-capture bug that [&] makes easy in C++, at the price of some awkwardness: accumulating into a captured local is impossible, so you use an array of one element, an AtomicInteger, or the stream operation that was the right answer anyway. A Java lambda is also not a distinct type — it is an instance of whatever functional interface the context expects, which is why the parameter is typed IntUnaryOperator rather than auto.

The reason C++ cannot have this is not neglect: a compiled C++ artifact is only compatible with code built the same way, so distributing binaries means distributing a matrix of them. The JVM defines binary compatibility precisely, so one jar works everywhere. What you give up is the ability to debug into a dependency's source or compile it with your own flags — and, in practice, a dependency tree that is far larger than a C++ project would tolerate, because adding one is so cheap.

The pieces map onto ideas a C++ programmer already has: an Arena is a scoped allocator whose close frees everything at once, a MemorySegment is a bounds-checked span, and a FunctionDescriptor is the signature written in a form the linker can use. The rules that carry over from JNI are the important ones — do not hold a pointer past the arena that owns it, and be careful about which thread calls in.