Java.CodeCompared.To/Rust

Java local variables are mutable unless declared final. Rust reverses the default: every let binding is immutable unless explicitly marked mut. This is not a style preference — the compiler rejects a reassignment to a non-mut binding as an error, catching an entire class of accidental-mutation bugs before the program runs.

Java's final is an opt-in annotation that most Java code omits, even though most local variables are never reassigned in practice. Rust flips this: immutability is free and automatic, and mutability is the deliberate, visible opt-in via mut. Reading Rust code, every non-mut binding is a guarantee, not a convention.

Both languages infer local variable types from the initializer. Java's var is a syntactic convenience only for local variables. Rust's inference is more powerful — the compiler can look forward through the rest of the function to determine a type, so annotations are rarely needed even when the initializer alone is ambiguous.

Java has no shadowing within the same scope — text would need a different name once its type changes. Rust's let introduces a brand-new binding each time, so re-using the identifier text with a different type is legal: the old binding is shadowed, not mutated. This idiom is common for a parse-then-use sequence without inventing throwaway names.

Rust const requires an explicit type annotation and can be declared at module scope, outside any function — unlike Java, where a compile-time constant must live inside a class as a static final field. A Rust constant has no fixed memory address; the compiler inlines its value at every use site.

This is the single biggest conceptual shift moving from Java to Rust. The JVM runs a garbage collector that scans reachable objects and frees the rest on its own schedule — this is not a tunable knob, it is the entire memory model. Rust has no garbage collector and no runtime at all: the compiler determines, at compile time, exactly one owner for each value, and inserts code to free that value's memory the instant its owner goes out of scope. There are no GC pauses because there is no GC.

In Java, assigning a reference-type variable to another variable copies the reference — both names point at the same heap object, and the garbage collector frees it once nothing points to it anymore. Rust has no such implicit aliasing for heap-owning types like Vec or String: assignment moves ownership, and the original binding becomes invalid. The compiler enforces exactly one owner for a given value at any time, which is precisely what makes deterministic, GC-free cleanup possible.

Java requires the explicit try-with-resources pattern (and an AutoCloseable implementation) to guarantee deterministic cleanup; ordinary objects are left to the garbage collector's own schedule, and a forgotten close() call is a common resource leak. In Rust, every value's owner is known at compile time, so the compiler can call the Drop trait's drop method automatically the instant the owner's scope ends — no special syntax required, and it is impossible to forget.

Passing a Java object reference to a method never removes access from the caller — the caller can keep using it afterward, since the GC keeps the object alive as long as anyone references it. Passing a Rust value by value (not by reference) moves ownership into the function; when the function returns, that value is dropped, and the caller can no longer use its original binding. The next section shows how to lend a value instead of moving it.

When a Java program needs an independent copy rather than a shared reference, it calls a copy constructor or factory method explicitly — the same conscious choice Rust requires with .clone(). The difference is what happens when you do not ask for a copy: Java silently shares the reference (both names alias the same object) while Rust silently moves ownership away from the original (the original name becomes unusable). Neither language ever copies a heap-allocated collection implicitly.

To avoid the move from the previous section, Rust lets you lend a reference with &value instead of passing the value itself. A shared reference (&T) grants read-only access and does not transfer ownership, so the original binding remains valid after the call — conceptually close to how every Java object reference behaves, except Rust makes the borrow visible in both the function signature and the call site.

Java has exactly one kind of object reference, and it is always capable of mutation — there is no compiler-enforced distinction between "I will only read this" and "I will modify this." Rust splits references into shared (&T, read-only) and mutable (&mut T, read-write), and a function that needs to mutate a borrowed value must declare &mut in its signature and the caller must pass &mut explicitly.

Java places no restriction whatsoever on aliasing: any number of variables can reference the same mutable object simultaneously, and nothing stops one of them from mutating it while another reads it — this is precisely how data races occur across threads. Rust's borrow checker enforces, at compile time, that for any value you may have either any number of shared references (&T) or exactly one mutable reference (&mut T), never both at once. This single rule is what makes Rust references memory-safe without a garbage collector and data-race-free without a runtime lock.

Java's enhanced for loop iterates references without ever affecting what the original collection variable can do afterward. Rust's for item in &collection mirrors this by borrowing each element; omitting the & (for item in collection) would instead move the collection into the loop and consume it, leaving fruits unusable afterward — a distinction with no Java equivalent, since Java references are never "consumed."

A Java method can freely return a reference to a locally created object because the garbage collector keeps that object alive for as long as any reference to it survives — dangling references are structurally impossible in Java. Rust achieves the same safety guarantee by a completely different route: the borrow checker refuses, at compile time, to let a reference outlive the value it points to. The fix shown here — returning the owned value itself rather than a reference to a local — is the standard idiom.

In Java, any reference-typed variable — String, any object, any collection element — can silently hold null, and the compiler gives no warning; the failure only appears as a NullPointerException at runtime, often far from where the null was introduced. The Java panel is marked non-runnable because it deliberately demonstrates that crash. Rust has no null value in safe code at all: a type like String can never be absent. Absence must be represented explicitly with Option<T>, and the compiler refuses to compile code that uses the value without first checking whether it is present.

Java 8's Optional<T> is a genuine improvement, but it is opt-in — nothing in the language prevents a method from returning a bare, nullable String right beside another method that wraps its result in Optional, and most of the JDK and most existing Java code predates Optional entirely, so null remains pervasive underneath. The Java panel is marked non-runnable because findUserNameUnsafe deliberately triggers that crash to make the point concrete. Rust has no equivalent escape hatch: every function signature makes optionality explicit in its return type, and there is no "raw," unchecked alternative to reach for instead.

Rust's Option<T> API closely mirrors Java's Optional<T>: .unwrap_or(default) parallels .orElse(default), and .map(function) transforms the contained value in both. The crucial difference is not the API shape but the coverage: in Rust, Option<T> is the only way any value can be absent, so this API is unavoidable rather than optional.

Java's Optional.isPresent() followed by .get() is a two-step check-then-extract pattern that the compiler cannot verify is used correctly — calling .get() on an empty Optional throws NoSuchElementException at runtime. Rust's if let Some(number) = value pattern-matches and binds the contained value in a single step; there is no separate unchecked extraction method to misuse.

Java has two exception categories: checked exceptions, which the compiler forces a caller to catch or declare in throws, and unchecked (runtime) exceptions like NumberFormatException, which can propagate silently through any number of stack frames with no compiler involvement at all. Rust has neither category, because it has no exceptions: a fallible operation returns Result<T, E>, and the possibility of failure is visible in every signature along the call chain, with no unchecked escape hatch.

Java signals failure by throwing and unwinding the call stack, transferring control to whichever catch block matches. Rust signals failure by returning a value — Result<T, E> is either Ok(value) or Err(error), an ordinary enum with no special control-flow behavior. Nothing "jumps" anywhere; the caller receives a Result and must inspect it like any other value.

Java's unchecked exceptions propagate invisibly — nothing at the call site of Integer.parseInt(input) signals that the line might transfer control elsewhere. Rust requires the ? operator at every fallible call site: it is shorthand for "return this Err immediately if there is one, otherwise unwrap the Ok value." Propagation is deliberate and visible at every single step of the call chain, not an automatic, invisible unwind.

Both sides of this example are marked non-runnable because both deliberately crash: Java's uncaught IndexOutOfBoundsException terminates the program, and Rust's panic does too. This is Rust's one concession to something exception-shaped: a panic! — triggered explicitly or by an operation like an out-of-bounds index — unwinds the stack and aborts, for conditions considered programmer bugs rather than expected failures. Unlike Java exceptions, panics are not typed, are not meant to be selectively caught, and there is no equivalent of a checked exception forcing you to handle one.

Java composes fallible steps with sequential statements inside a single try block — any of them can throw, and the catch block handles whichever one did. Rust composes them functionally: Result::map(f) applies f only if the result is Ok, leaving Err untouched, and Result::and_then(f) does the same when f itself returns a Result. This builds an explicit pipeline of fallible steps without a shared, ambient try block.

A Java class bundles fields, constructors, and methods in one declaration. Rust separates data from behavior: a struct declares only fields, and any number of separate impl blocks attach methods to it. There is no constructor in the Java sense — a Point value is built directly with struct-literal syntax, Point { x: 3, y: 4 }, or through an ordinary associated function you define yourself (see the next concept).

Java constructors are a distinct language construct, invoked with new ClassName(...). Rust has no constructor syntax at all — new is just a conventional function name, not a keyword. Any function inside an impl block that does not take self as its first parameter is an "associated function," called with Type::function(...), exactly like Java's static factory methods (Point.origin()).

Java's implicit this is always mutable and never distinguishes a read-only method from a mutating one at the type level. Rust methods declare their receiver explicitly: &self borrows the instance read-only, &mut self borrows it mutably (required for any method that changes a field), and plain self (rare) consumes the instance entirely. The borrow-checker rules from the ownership sections apply to self exactly as they do to any other reference.

Java records (since Java 16) auto-generate equals, hashCode, and toString for a data-only type — a close parallel to Rust's #[derive(...)] attribute, which auto-implements traits like Debug (developer-readable printing) and PartialEq (== comparison) for a plain struct. Rust's derive list is more granular and extends beyond equality/printing to traits like Clone, Copy, Hash, and Ord, each opted into independently.

A Rust trait with a default method reads almost identically to a Java interface with a default method — both declare required methods plus optional ones with a shared implementation. The syntax difference is structural: Java's implements appears on the class declaration, while Rust's impl Trait for Type is a separate block, which is what enables the next concept — implementing a trait on a type you do not own.

This has no equivalent in Java at all. Java's String is final and you do not own it, so you cannot make it implement a new interface — a static utility method (isPalindrome(str)) is the only option, and it never reads like a method call on the string itself. Rust allows implementing your own trait on any type, including built-in types like str or types from other crates, as long as either the trait or the type is defined in your own code (the "orphan rule"). This is genuinely new territory for a Java developer, and it is how much of Rust's idiomatic ergonomics — extension-method-like APIs on foreign types — are built.

Java's <T extends Comparable<T>> and Rust's <T: PartialOrd> serve the same purpose — restricting a generic type parameter to types that support a particular operation. Rust also supports a more readable where-clause form for complex bounds: fn maximum<T>(first: T, second: T) -> T where T: PartialOrd, useful when a function has several type parameters with several bounds each.

A Java List<Shape> holding mixed Circle and Square instances uses ordinary runtime polymorphism — every object reference already carries type information. Rust achieves the same runtime-polymorphic collection with Vec<Box<dyn Shape>>: dyn Shape is a "trait object" resolved via a vtable at runtime (like a Java interface reference), and Box heap-allocates each value since a dyn Shape has no fixed compile-time size on its own. This is the deliberately-opted-into dynamic-dispatch counterpart to the compile-time impl Trait/generic style used elsewhere in this cheatsheet.

A plain, dataless enum works almost identically in both languages — a fixed set of named values, accessed via the type name (Direction::North in Rust, Direction.NORTH in Java). The #[derive(Debug)] attribute is needed for the {:?} print format, since Rust enums do not automatically implement a string representation the way Java's enum inherits toString() from java.lang.Enum.

This is where Rust enums leave Java's enum far behind: each variant of a Rust enum can carry its own distinct payload shape — Circle(f64) carries one number, Rectangle(f64, f64) carries two — all under a single type, Shape. Java's enum constants share one fixed set of fields across every constant; there is no way to give CIRCLE a radius field and RECTANGLE a width/height pair on the same enum. A true Rust-style algebraic data type in Java requires the sealed-interface-plus-records pattern shown in the next concept.

Java 17's sealed interfaces (restricting which types may implement an interface) combined with records and Java 21's exhaustive pattern-matching switch genuinely close most of the practical gap with Rust enums — the same "the compiler proves I handled every case" guarantee is achievable in modern Java. The remaining difference is ergonomic and structural rather than a missing capability: Rust expresses the whole algebraic data type as one enum declaration, while Java assembles the same idea from three separate features (a sealed interface, one record per variant, and pattern-matching switch). The turbofish (::<&str>) on the second call is required because the Error variant does not mention T, so nothing in that call lets the compiler infer it — Java's new Failure<>("not found") has no analogous inference gap since Failure<T> is a distinct type per generic instantiation, not a shared variant of one enum.

Java's modern switch expression and Rust's match read almost identically for simple value matching. Rust uses _ as the wildcard arm where Java uses default. The bigger difference shows up on non-trivial types: Rust match is exhaustive over every enum, always, with no sealed keyword required to opt in — exhaustiveness is simply how enums work in Rust.

Java only gets compiler-enforced exhaustiveness if the type hierarchy is explicitly marked sealed — an ordinary interface or a non-final class hierarchy compiles a switch missing a case without complaint, silently leaving a gap that surfaces at runtime. In Rust, every enum is implicitly closed — you cannot add a variant from outside the module without changing the enum declaration itself — so match exhaustiveness checking applies universally, with no opt-in keyword and no way to accidentally skip it.

Java 21's record patterns with when guards can express the same destructuring logic as Rust's tuple/struct patterns, but Rust's wildcard _ inside a pattern (matching "any value, don't bind it") is more concise than Java's repeated when guard clauses for the same purpose. Rust patterns can also destructure directly in let bindings, function parameters, and for loops — not only inside match.

Java 21 pattern matching requires a when guard clause to express a numeric range comparison inside a switch. Rust has first-class inclusive range patterns (90..=100) that need no guard at all for this common shape; a Rust match guard (score if score % 2 == 0 => ...) is reserved for conditions a pattern alone cannot express, such as comparing two bound variables to each other.

Java generics are compiled away entirely by type erasure: at runtime, List<String> and List<Integer> are both plain List, with no way to recover the type argument via reflection — this is the source of Java's notorious "unchecked cast" warnings. Rust generics use monomorphization instead: the compiler generates a completely separate, specialized copy of the function or type for every distinct type argument it is used with, so there is no erasure and no runtime type-information loss. The tradeoff is larger compiled binaries (one copy per instantiation) in exchange for zero runtime overhead — generic code runs exactly as fast as if it had been hand-written for that one specific type.

A generic Rust struct<T> alongside a generic impl<T> block closely mirrors a Java generic class. The more instructive difference is the return type of pop(): the Java version throws an unchecked exception on an empty stack (or requires a manual empty-check first), while the Rust version returns Option<T> — None for an empty stack rather than a runtime crash, following the "no null, no exceptions" theme running through this whole cheatsheet.

Java combines multiple bounds on a type parameter with &: <T extends Comparable<T> & Serializable>. Rust uses + for the same purpose: <T: PartialOrd + Debug> requires T to implement both traits. Both mechanisms exist to let a generic function call methods from more than one contract on its type parameter.

Vec<T> is Rust's equivalent of ArrayList<T> — a heap-allocated, growable, contiguous sequence. Because Rust has no type erasure, Vec<i32> stores unboxed integers directly, with none of the boxing overhead Java's ArrayList<Integer> pays for every element. The vec![] macro is the idiomatic literal syntax, and .push/.len map directly to .add/.size().

The two HashMaps share a name and behave the same way conceptually. Java's .put(key, value)/.get(key) become Rust's .insert(key, value)/index or .get(key); Rust's .get() returns Option<&V> rather than null, so .copied().unwrap_or(default) is the direct analog of .getOrDefault(key, default).

Java's Map.merge(key, value, function) and Rust's .entry(key).or_insert(default) both perform an insert-or-update with a single hash lookup, avoiding the classic double-lookup of checking presence and then inserting or updating separately. Rust's entry API returns a mutable reference you dereference with * to modify in place, which reads less like a one-liner but composes with any update logic, not only summation.

Both languages have fixed-size arrays, but Rust's [T; N] bakes the length into the type — [i32; 4] and [i32; 5] are distinct types, and the length is known and checked at compile time. Java arrays are always heap-allocated objects with a runtime-checked length property; Rust arrays are typically stack-allocated (unless boxed), giving them performance characteristics closer to C arrays. Use Vec<T>, not [T; N], whenever the size is not known until runtime.

Java lambdas implement a functional interface (Function<T, R>, Supplier<T>, etc.) and are invoked through that interface's single abstract method (.apply(...)). Rust closures use |params| body syntax and are called directly like a regular function, double_it(5) — no interface, no .apply indirection.

Java requires a captured local variable to be "effectively final" — never reassigned after initialization — because the lambda captures its value, copying it in. Rust closures capture by the least-restrictive method that still compiles: borrowing first, then mutable borrowing, then moving. The move keyword forces ownership to transfer into the closure, which is required whenever the closure must outlive the function it was created in — for example, when spawning a thread, covered later in this cheatsheet.

Java Streams and Rust iterator chains solve the same problem with a strikingly similar shape: lazy, chainable .filter()/.map() operations that only run when a terminal operation (.sum(), .collect()) consumes them. The underlying cost model differs: a Java Stream boxes primitives when crossing generic boundaries and its lambdas are heap-allocated closures, while Rust's iterator adapters are zero-cost — the compiler inlines and monomorphizes the whole chain into code as fast as a hand-written loop, with no allocation for the closures themselves.

Java Stream methods .anyMatch, .allMatch, and .findFirst map directly onto Rust's .any(), .all(), and .find(). Java's Optional-returning .findFirst() parallels Rust's Option-returning .find() — both make "might not find anything" explicit in the return type rather than throwing or returning a sentinel value.

Java's Thread and Rust's thread::spawn look nearly identical at this surface level — both hand a closure/lambda to a new OS thread and both support joining. The difference appears the moment the thread touches shared mutable state, covered next: Java lets you write a data race that compiles fine and fails unpredictably at runtime, while Rust refuses to compile the equivalent code at all.

This is "fearless concurrency," Rust's signature claim, made concrete: the unsynchronized Java version on the left compiles without a single warning and produces a nondeterministic result at runtime — a data race the type system never saw. The Rust version could not express the same mistake even if you tried: sharing mutable state across threads requires Arc (atomic reference counting, for shared ownership) wrapping a Mutex (for exclusive access), and the borrow checker refuses to compile any access to the inner value that does not go through .lock(). The same ownership and borrowing rules that apply within a single thread extend across threads, so a whole category of concurrency bugs becomes a compile-time error instead of an occasional, hard-to-reproduce test failure.

Java's BlockingQueue and Rust's std::sync::mpsc::channel both let threads communicate by passing ownership of messages rather than sharing mutable memory — "share memory by communicating" is a design philosophy Rust inherited partly from Go. The Rust compiler additionally enforces that a value sent through a channel is moved into the channel: the sending thread can no longer access it afterward, so there is no risk of the sender and receiver both mutating the same message concurrently.

The Rust side is deliberately left non-runnable — the whole point is that this code does not compile. This is the single most common early frustration moving from Java to Rust: code that "obviously" works — reading an old reference while appending to the same vector — is routinely rejected by the borrow checker, because numbers.push(4) might reallocate the vector's backing storage, which would leave first pointing at freed memory. Java's garbage collector sidesteps this entire class of bug at the cost of never catching it at compile time; Rust catches it every time, but expect a real learning curve reworking code the compiler rejects, especially in the first few weeks.

Rust has no extends, no base classes, and no "is-a" relationships at all — a Java developer's habit of reaching for a class hierarchy to share behavior does not transfer directly. Shared behavior in Rust comes from implementing the same trait on unrelated types (what Dog and Cat have in common is that both implement Speak, not that both extend Animal) and shared data comes from composition — a struct holding another struct as a field — rather than a base-class field being inherited. This is a genuine redesign exercise for anything modeled as a deep Java class hierarchy, not a syntax swap.

Both sides are marked non-runnable since config.txt does not exist in this sandboxed environment — the interesting part is the shape of the code, not its output. Java exceptions, even checked ones, still bubble up through the call stack automatically once thrown — a developer only sees a marker (throws) at each intermediate function, not an action. Rust requires the ? operator at the exact call site of every fallible operation, all the way up the chain; there is no automatic bubbling. This is more verbose but leaves nothing implicit — you can always see precisely where a failure can originate and where it is handled, at the cost of typing ? far more often than throws appears in equivalent Java.

Expect Rust compile times — particularly clean builds and builds that stress generics or trait resolution — to be noticeably longer than the equivalent javac invocation, and expect that tradeoff to be worth it: the entire class of runtime failure Java accepts as a cost of doing business (null dereferences, data races, use-after-free, none of which are possible in safe Rust at all) is instead caught during that longer compile. The mental shift this requires is real: a Java developer used to "it compiled, let's see if it works" has to adjust to "if it compiles, several categories of bug are already provably absent" — and, correspondingly, to spending more time satisfying the compiler up front rather than debugging failures after deployment.