C.CodeCompared.To/Java

System.out.println appends the newline and knows how to render whatever you hand it; printf takes a format string and believes it. Note also what is missing from the Java side: no return 0, because main returns void and the exit status comes from System.exit or from falling off the end normally. Java does have System.out.printf with many of C's conversion specifiers (%d, %s, %x, %5.2f), for when you want the field widths — though C's %u, %ld and %zu throw an exception there.

The off-by-one between argc - 1 and args.length is the kind of difference that survives a mechanical translation and then produces a wrong answer. Note too that System.exit does not run any pending finally blocks — it is the abrupt exit, the same as C's, while returning normally from main lets the JVM shut down in an orderly way.

Two differences. %n rather than a backslash-n escape emits the platform line separator, which is what printf in Java is documented to prefer. And the format string is checked at run time, not compile time — a mismatched conversion throws IllegalFormatConversionException rather than being caught by -Wformat, so a C habit of trusting the compiler here does not transfer. String.format is the same machinery returning a string instead of printing.

Java removed sizeof because it removed the question. The cost is the other half of the trade: apart from the 16-bit char, Java has no unsigned integer types. A C unsigned int arriving over JNI has to be carried in a Java int and read with Integer.toUnsignedLong or Integer.compareUnsigned, and a value above 2³¹−1 looks negative until you do.

The gain is that the usual-arithmetic-conversions trap disappears: -1 < 1u is false in C because the signed operand converts to unsigned — GCC's -Wextra warns about comparing the two, but it compiles — and there is no way to write that mistake in Java. The cost shows up at a byte boundary — a byte is signed, so a byte read from a file arrives as −1 rather than 255, and value & 0xFF is the idiom you will write constantly. Integer.toUnsignedString, Long.compareUnsigned and Integer.divideUnsigned exist for when the bits really are unsigned.

The consequence bites in two directions. A Java char[] is not a byte buffer, so handing one to C as a char* is wrong by a factor of two — byte[] is the counterpart. And because a UTF-16 unit cannot hold every code point, characters outside the Basic Multilingual Plane take two chars, which is why String.length() counts code units rather than characters.

That is mostly a relief and occasionally a loss. You cannot compute a buffer size, cannot control padding, and cannot know how much an object costs without a profiler — which matters when you are used to laying out a struct deliberately. Integer.BYTES and friends give you the primitive widths as constants. The nearest thing to control over layout is choosing primitive arrays over object graphs, and Project Valhalla is the long-term answer.

The reason is the collector: it moves objects to compact the heap and rewrites the references it knows about, which it could only do if no program can hold a raw address. That single constraint is what buys the whole safety story, and it is why every C idiom built on address arithmetic — walking a buffer with a moving pointer, packing a tagged pointer, casting a struct to char* to serialize it — needs rethinking rather than translating. ByteBuffer and the Foreign Function and Memory API are where that work goes.

A record generates its constructor, accessors, equals, hashCode and toString, so the C-style pattern of an out parameter — which exists mostly to avoid the cost of returning a struct — becomes cheaper to write than it was in C. Note that Java can modify what a reference points at, so a method taking an array or a list can fill it in; what it cannot do is replace the caller's variable, which is what int ** is for in C.

Java is pass-by-value throughout, and the value being passed is the reference — which is why modify can change the object's field but could not make the caller's variable point at a different object. That is exactly C's Box * versus Box ** distinction, with the second one simply unavailable. The absence of pointer arithmetic is what lets the collector move objects and rewrite the references.

A NullPointerException is the runtime having compared against zero and lost — which is why it arrives as a catchable object with a stack trace rather than as a crash. Since Java 15 the message also names the expression that was null (a local variable appears as <local1> unless the class was compiled with -g), which is the part C can never offer: by the time the hardware faults, the information about which subexpression it was has already been thrown away.

The performance consequence is the one to carry: grid[1][2] in C is one multiplication and one load, and in Java it is two loads with a bounds check each, into memory that may be anywhere. For numeric work the usual answer is a flat int[] with your own index arithmetic — which is what C was doing for you. What Java gains is ragged arrays, and that a row can be passed on its own because it carries its own length.

The sizeof(numbers) / sizeof(numbers[0]) idiom is correct in main and would count 2 inside sum — a pointer's 8 bytes over an int's 4 — because there the name is a pointer. GCC warns that such a division does not compute the number of array elements, but builds it anyway. That is the single most common source of buffer overruns in C, and Java removed the possibility by making the length part of the object. The for (int value : values) form exists because the loop no longer needs an index to stay in bounds.

The C check had to be written, and had to use an unsigned type so a "negative" index wraps to something enormous and still fails. Java's check is not free either — it is a compare and a branch on every access — but the JIT removes most of them by proving the bound once, which is why the enhanced for loop is usually faster than indexing.

The rule that goes with it: a String is immutable, so result += piece in a loop allocates a new string every iteration, which is quadratic. That is the one performance mistake a C programmer is likely to make here, and it is the reverse of the C instinct — in C you would reuse a buffer, and in Java you use StringBuilder for exactly the same reason. Outside a loop, + is compiled into efficient code and is the readable choice.

C reports 2 where Java reports 5, and that disagreement is the lesson: a zero byte terminates one and is data in the other. Immutability is the other half — substring hands back a new object rather than writing into a buffer you sized, so there is no + 1 to forget and no overflow to cause. The cost is that building a string in a loop allocates repeatedly, which is what StringBuilder exists to avoid.

This is the one place where Java's syntax being C-like is actively dangerous: first == second is a type error nowhere and wrong nearly everywhere. It is made worse by string interning — two identical literals are the same object, so "hello" == "hello" is true and the bug hides until a string arrives from input. The new String(...) above defeats interning to make the comparison honest.

What goes away: leaks from a forgotten free, use-after-free, double-free, and the design work of deciding who owns what. What arrives: you cannot say when memory is reclaimed, the heap is several times the size of the live data, and a pause can happen at an awkward moment — though modern collectors such as ZGC keep those under a millisecond. Java can still leak in the ordinary sense: an object reachable from a long-lived collection is never collected, and that is the leak you will actually meet.

Memory is not what this is for, since the collector handles that; it is for the things a collector cannot help with, which are exactly the things goto cleanup released in C: files, sockets and native handles. Anything implementing AutoCloseable works — which a Lock is not, so a lock is released with synchronized or in a finally. Resources close in reverse order of acquisition, and an exception thrown by close() is suppressed rather than replacing the original — getSuppressed() retrieves it, which is better than C, where a failing cleanup usually just gets ignored.

Three things vanish at once: the failure check, the free, and the uninitialized memory — new int[4] is guaranteed zeroed while malloc gives you whatever was there. What you give up is knowing when memory is released. That imprecision is why Java needed try-with-resources for things that are not memory: the collector handles the heap but has nothing to say about a file handle or a socket.

Two things a C programmer gains here. A lambda captures surrounding values, so the void *user_data parameter that every C callback API carries is unnecessary. And the comparator cannot be mismatched to the array, because the types are checked — where qsort will happily accept a comparator written for a different type and produce nonsense. What you give up is that Integer[] boxes; sorting an int[] uses the primitive Arrays.sort, which takes no comparator at all.

What replaces the C meanings: private is the visibility control, enforced by the compiler rather than by linkage, and a value that must persist between calls becomes a field. Java also has no global namespace to collide in — a class is always inside a package (the unnamed package, when the file declares none, as every example here does), so the prefixing convention that gives C png_read_info and sqlite3_open is unnecessary. Note that a static field is shared by every thread, which makes it the usual home of a threading bug.

The mechanical change is small — counter_add(&counter, 5) becomes counter.add(5) — and the real addition is private. In C the struct's fields are visible to every file that includes the header, and the convention that only counter_* functions touch them is enforced by nothing — unless the header declares only an opaque struct Counter; and hands out pointers, the one way C has of hiding fields. Java made that convention a compile error, which is most of what "encapsulation" buys.

Platform differences become run-time branches (System.getProperty), and what would have been a build flag becomes configuration. The related loss is debug builds. The one form of conditional compilation Java has is an if on a static final boolean constant: javac leaves the dead branch out of the class file, so if (DEBUG) with DEBUG = false compiles logging away — but only by editing the source, never from a build flag. Logging frameworks therefore use a run-time level check — and if (logger.isDebugEnabled()) exists precisely to avoid building a message that will be discarded. assert stays in the class file and is skipped at run time: it is disabled by default, and java -ea turns it on.

The two columns disagree on the last two numbers, and that is the point: SQUARE(counter++) expands to ((counter++) * (counter++)), which increments twice and is in fact undefined behavior for reading and modifying the same object twice without a sequence point. A method cannot do that. Losing #ifdef also means Java has almost no conditional compilation — only an if on a static final boolean, which javac compiles away — so platform differences are handled at run time instead, which is what "write once, run anywhere" is really describing.

That directly addresses the biggest source of real C bugs — an ignored return value. Nothing in C makes you check what parse returned, which is why -Wall -Wextra and static analysis are not optional there. The counter-argument, argued about for twenty years, is that checked exceptions also produce empty catch blocks written to satisfy the compiler. Extending RuntimeException makes an exception unchecked, which is what most modern libraries do.

This is most of the difference between diagnosing a production failure in the two languages. A C program that dies gives you a signal and, if you configured it, a core file; a Java one gives you the frames in the log. 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.

The C column is not exaggerated: strtol genuinely reports "not a number at all" only by leaving the end pointer where it started, and genuinely requires clearing errno first because it is not cleared on success. What Java adds beyond brevity is that the failure carries information — a type, a message, and the stack — and that a finally block runs on the way out, which C's goto cleanup idiom achieves only if every early return remembers to jump.

The habit worth changing along with it: reach for ArrayList rather than LinkedList. A C programmer's instinct that a linked list is the natural sequence comes from it being the one that is easy to hand-roll, but a growable array wins on nearly every real workload because it is contiguous — the same cache argument that makes a C array fast. LinkedList exists in Java and is almost always the wrong choice.

Generics check it at compile time, so a container cannot be read as the wrong type — unless a raw type or an unchecked cast opts out, and then the mistake surfaces as a ClassCastException at the read. The caveat a C programmer should know is that Java generics are erased — List<String> and List<Integer> are the same class at run time, there is no new Element[10], and a primitive cannot be a type argument, so List<Integer> costs an object per element. That is closer to void * underneath than it looks; what changed is that the compiler now proves the casts are right, for code that does not opt out.

The C version is a linear scan — fine for three entries, wrong for three thousand — and deciding when to graduate to a real hash table is a judgment Java made once, for everyone. Note the shape that survives translation: get returning null for a missing key is the same "found/not found" signal as the C function's return value, and it exists for the same reason, because a zero value is otherwise indistinguishable from a missing one.

Definite assignment analysis is the part with no C counterpart: the compiler proves every path assigns the variable before it is read, so the class of bug where a value depends on stack contents cannot occur. That closes one of the favorite doors for security researchers, since uninitialized memory frequently holds something interesting from a previous allocation. The C habit worth keeping anyway — initialize at the point of declaration — is still good style here.

This belongs in the same family as overflow and shift counts: Java chose to nail down behavior that C left open for the optimizer. The everyday consequence is that i++ + i++ and its relatives — which are undefined in C, not merely unspecified — have defined answers here. It is not licence to write them; it is one fewer class of portability bug, and it is why a single-threaded Java expression gives the same answer on every implementation in a way a C expression does not.

This is the deepest difference on the page and the one with no syntax to see. In C, "it wrapped on my machine" is not a guarantee — the optimizer is allowed to delete an overflow check on the grounds that overflow cannot occur, and it does. Java has no undefined behavior as a category: evaluation order is left-to-right, integer sizes are fixed, and arithmetic gives the same answer everywhere. (What still varies is what the specification leaves open on purpose: the interleaving of a data race, and the iteration order of a hash map.) That predictability is bought with the bounds checks and the null checks in the rows above.

The pieces map onto C ideas directly, which is why this is the easier direction to learn. An Arena is a scoped allocator whose close frees everything at once — the goto cleanup block as a language feature. A MemorySegment is a pointer that carries its length and is bounds-checked, which is the pointer-plus-count pair you already pass everywhere, made into one value. A FunctionDescriptor is the prototype, written where the linker can use it.

Three things must agree and none is checked at compile time: the mangled symbol name, the parameter widths, and the presence of the library at run time — a mismatch surfaces as UnsatisfiedLinkError. The widths are the merciful part: jint and jlong are fixed at 32 and 64 bits, so unlike C-to-C interop there is no platform ambiguity. The unsigned gap remains, though — a C unsigned long has no Java counterpart and must be carried in a long and read with Long.toUnsignedString.

Java had the first memory model of any mainstream language, and C11 followed it, so the concepts line up: volatile in Java is roughly C11's atomic with sequential consistency — and is not C's volatile, which means something else entirely. The difference that matters is the failure mode: a data race in Java gives you a stale or torn value, while in C it is undefined behavior. Prefer ExecutorService over raw threads, and see the next row for why blocking is cheap now.

The consequence is that the whole asynchronous style — an event loop, callbacks, state machines, never blocking — becomes unnecessary for input-and-output-bound work. Write the straightforward blocking code and run it on a virtual thread. C's equivalents are all libraries with their own control flow (libuv, io_uring wrappers, a coroutine framework), and none of them is in the standard.

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 on every JVM at least as new as the one it was compiled for (an older JVM refuses it with UnsupportedClassVersionError). What you give up is compiling a dependency with your own flags and stepping into its source — and, in practice, a dependency tree far larger than a C project would tolerate, because adding one is so cheap.