Java.CodeCompared.To/Swift

Swift needs no class, no main method, and no System.out — a top-level print() is a complete program (the file's top-level statements are the entry point). Statements need no semicolons, and print adds a newline like println. The ceremony a Java program requires around main simply does not exist.

Swift compiles to a native binary like Java compiles to bytecode, but swift main.swift runs a file directly in script mode with no separate javac step, and the result is a standalone executable that needs no JVM. On Apple platforms Xcode and Swift Package Manager (swift build/swift run) replace Maven and Gradle.

Swift shares Java's // and /* */ comments, but Swift block comments nest correctly, so you can comment out a region that already contains a block comment. Documentation uses /// (or /** */) with Markdown, the counterpart to Javadoc, surfaced in Xcode's Quick Help.

Swift inverts Java's default: let declares a constant (Java's final) and var declares a mutable variable, and the immutable form is the one with the shorter keyword — so idiomatic Swift reaches for let first. The compiler even warns when a var is never mutated, nudging you toward let.

Both languages infer types from the initializer — Java's var (since 10) and Swift's let/var. Swift's inference is more pervasive: it flows through generic calls and closures, so annotations are rarer. When you do annotate, the type follows the name after a colon (let typed: Int64), the reverse of Java's Int64 typed order.

Java silently widens numeric types (int to long, int to double). Swift never converts between numeric types implicitly — you wrap the value in the target type (Int64(count), Double(count)) every time. This is stricter than Java but eliminates surprises from automatic promotion in mixed-type arithmetic.

Swift has built-in tuples — lightweight, optionally labeled groupings written with parentheses — where Java reaches for a record or an array. A tuple is ideal for a transient pairing you do not want to name a type for, and it destructures directly into multiple bindings (let (name, age) = person), which Java records do not.

This is the single biggest safety difference. In Java any reference can be null, and dereferencing it throws a NullPointerException at runtime. Swift bakes nullability into the type: String? may be nil, a plain String can never be, and the compiler refuses to let you use an optional without unwrapping it first. The NPE class of bug is eliminated at compile time.

Java added Optional<T> as a library type with isPresent()/get(), but it is opt-in and ordinary references stay nullable. Swift's if let actualName = name unwraps the optional into a non-optional binding scoped to the if block — a language feature, not a wrapper class. Since Swift 5.7 you can shorten it to if let name when the names match.

Swift's guard let is the idiomatic early-exit unwrap: unlike if let, the binding stays in scope for the rest of the function, so the "happy path" continues unindented. The else branch must leave the scope (return, throw, break, or continue). It turns Java's scattered null-guards into one declarative statement that both checks and unwraps.

The ?? operator returns the optional's value if present, or the right-hand default if it is nil — replacing Java's x != null ? x : fallback ternary (or Optional.orElse). The compiler verifies the default matches the unwrapped type, and the operators chain, so a ?? b ?? c tries each in turn.

Swift's ?. short-circuits a whole chain to nil if any link is absent, so user?.address?.city is safe even when user is nil. Java has no optional-chaining operator: you write nested null checks or chain Optional.map calls. Combined with ??, the entire safe-navigation-with-default collapses to one readable line.

Swift interpolates any expression directly into a string literal with \(expression) — no String.format and no positional %s/%d specifiers to keep in sync with their arguments. The interpolation is type-checked, and any type that is printable can be embedded, including the result of a method call or arithmetic.

Swift's string methods read much like Java's, with small naming differences (uppercased() vs toUpperCase(), .count vs .length). A deeper difference: a Swift String is a collection of grapheme clusters (user-perceived characters), so .count reflects what a reader sees, and you cannot index a string with a plain integer — emoji and combined characters count as one.

Both languages use triple-quoted text blocks for multi-line strings, and both strip the indentation up to the closing delimiter. Java added text blocks in 17; Swift has had them since 5.0. Inside a Swift multi-line string you can still interpolate with \(...), and a trailing \ joins a line to the next without a newline.

A Swift Array is the everyday growable sequence, written as a literal with no new ArrayList<>() ceremony and no separate List interface. Mutability comes from the binding: a var array can append, a let array is fixed. It uses .count and subscripting fruits[0] rather than .size() and .get(0).

Swift's map/filter/reduce are methods directly on the array — there is no separate .stream() to open or terminal operation to close as in Java. The $0 shorthand names the first closure argument, and reduce(0, +) passes the + function itself. The result is eager (a new array), not a lazy stream, unless you ask for .lazy.

A Swift Dictionary uses a brace literal with colons and subscript access. Crucially, subscripting returns an optional (ages["Alice"] is Int?) because the key might be absent — the type system forces you to handle the missing case, where Java's get silently returns null. Pair it with ?? 0 for Java's getOrDefault behavior.

Swift's Set is a built-in collection like Java's, but it shares the array literal syntax, so you annotate the type (let numbers: Set = [...]) to choose a set over an array. It offers the same algebra — intersection, union, subtracting — as methods rather than Java's retainAll/addAll mutators, returning new sets.

Swift conditionals drop the parentheses around the condition but require braces even for a single statement — there is no brace-less if, which removes a class of bug. The condition must be a genuine Bool; Swift has no truthiness, so if someInt or if someOptional alone is a compile error (use != 0 or != nil).

Both have switch expressions with no fall-through (Java since 14 with ->; Swift always). Swift's switch is exhaustive over its type, so a switch on an enum must cover every case or the compiler rejects it. Swift cases also match ranges (1...5), tuples, and bind associated values — far more than constant labels.

Swift has no C-style counting for; you iterate a range instead. 0..<3 is a half-open range (0, 1, 2) and 1...5 is closed (1 through 5). The enhanced-for over a collection looks like Java's for (x : items) with in instead of :. To get an index alongside the value, iterate array.enumerated().

Swift's while matches Java's. The do-while loop is spelled repeat { ... } while in Swift — do was reserved for error handling (do/catch), so the bottom-tested loop got a different keyword. Note count += 1: Swift has compound assignment but deliberately removed the ++ and -- operators in Swift 3.

A Swift func declares its return type after ->, and a top-level function needs no enclosing class or static — functions are first-class and can live anywhere. The parameter type follows the name after a colon. Note the call site uses the parameter name (greet(name:)) — Swift's argument labels are part of a function's identity.

Swift functions have external argument labels distinct from internal parameter names: move(from: 2, to: 9) reads like prose at the call site while the body uses start and end. An underscore (_ first: Int) suppresses the label for a positional call. Java parameter names are invisible to callers, so this expressiveness has no Java equivalent.

Swift parameters can declare default values (port: Int = 5432), so a single function covers what Java needs a family of overloads for. Callers omit any defaulted argument, and combined with argument labels this removes most of the telescoping-overload and builder-pattern boilerplate common in Java APIs.

Swift returns multiple values as a labeled tuple — (min: Int, max: Int) — with no named record or wrapper class to declare, the way Java now does with a record. The caller reads result.min by label or destructures with let (low, high) = .... The built-in min()/max() on the array return optionals, force-unwrapped here with !.

Swift closures are written { parameters in body } and have a plain function type (Int) -> Int — there is no Function/BiFunction/Supplier interface zoo as in Java, and you call a closure directly (doubler(21)) rather than through .apply(). Any function type is first-class, so closures, methods, and free functions are interchangeable.

When a closure is a function's last argument, Swift lets you write it after the parentheses (or omit empty parentheses entirely) — numbers.sorted { ... }. This "trailing closure" syntax is why Swift APIs read so fluently and underpins SwiftUI's declarative blocks. Java lambdas always sit inside the call's argument list.

A Swift closure captures variables by reference and can freely mutate them, so the counter's count survives and increments across calls. Java captures only effectively final variables, forcing the one-element-array trick to hold mutable state. Swift's capture is more direct, though you use a capture list ([weak self]) to avoid reference cycles when capturing objects.

This is a defining Swift difference. A struct is a value type: assigning it copies the whole value, so mutating second leaves first untouched. Every Java object is a reference type, where second = first aliases one object. Swift favors structs for data because copies are independent, inherently thread-safe, and free of aliasing surprises.

Swift class instances are reference types like every Java object — multiple variables can share one instance. Notice let counter still allows calling increment(): for a class, let fixes the reference, not the object's mutable state. Swift instantiates by calling the type name (Counter()) with no new, and uses private/internal/public access control like Java.

A Swift struct gets a memberwise initializer for free — Person(name:age:) is synthesized from the stored properties, much like a Java record's canonical constructor. Unlike a record, a struct's properties can be var (mutable) and you can add methods freely without it ceasing to be a value type, so it covers far more than immutable data carriers.

Because a struct is a value type, a method that changes its own properties must be marked mutating — the keyword makes the mutation visible and is only callable on a var instance, never a let. Java classes mutate fields silently. This is Swift signalling, at the type level, exactly which operations alter a value versus merely read it.

A Swift computed property looks like a stored property to callers (circle.area, no parentheses) but runs code each time it is read. Java models this as a getter method (area()). Computed properties can also have a setter, letting you expose a derived value that, when assigned, updates the underlying stored properties — a clean alternative to paired getter/setter methods.

Swift's willSet/didSet observers run code automatically whenever a stored property changes, without routing every access through a setter method as Java requires. Callers assign the property directly (account.balance = 100) and the observer fires — keeping the natural assignment syntax while still reacting to changes.

Swift's static properties and methods belong to the type, like Java's static members, and are accessed through the type name (Temperature.toKelvin). A static let is also lazily initialized and thread-safe on first access with no extra effort, addressing the double-checked-locking ceremony Java sometimes needs for lazy static singletons.

A Swift protocol is close to a Java interface: a compile-time contract a type adopts after a colon. The big difference is that protocols can require properties (var name: String { get }), and — unlike Java interfaces — value types (structs and enums) adopt them freely. Swift leans on protocols as its primary abstraction, a style called "protocol-oriented programming."

Java interfaces gained default methods in 8. Swift supplies defaults through a protocol extension — a separate extension block — which keeps the protocol's contract clean and lets you add behavior to a protocol you do not own. Conforming types inherit the implementation and may override it, and it works for structs and enums, not just classes.

Like Java, a Swift type can adopt several protocols by listing them with commas, composing capabilities from independent contracts instead of inheriting from one base class. Swift can also compose protocols on the fly with some Wheeled & Motorized as a parameter type, requiring a value that satisfies both — a lightweight intersection Java expresses only with generic bounds.

An array typed [Shape] holds any conforming value and dispatches area() dynamically, exactly like a Java List<Shape>. The structs here are value types yet behave polymorphically through the protocol — Swift boxes them in an "existential" automatically. Note that String(format:) comes from Foundation, imported at the top — Swift's core library keeps C-style formatting out of the base language.

Both languages have true enum types whose cases are known at compile time, enabling exhaustive switch. Swift cases are lowercase by convention and are written case north, south. When the type is known, you can abbreviate Direction.north to just .north — a leading-dot shorthand that appears throughout Swift wherever the expected type is unambiguous.

A Swift enum can declare a raw backing type (: Int, : String) and a literal per case, accessed via .rawValue — far less boilerplate than Java's field-plus-constructor pattern. The synthesized failable initializer Status(rawValue: 1) converts a raw value back to a case, returning an optional (nil if no case matches), which is ideal for decoding.

This is one of Swift's most powerful features. An enum case can carry its own associated data — success(Int) versus failure(String) — making the enum a true algebraic data type. A Java enum cannot do this; the nearest equivalent is a sealed interface with record implementations. A Swift switch then binds the payload (let value) and is checked for exhaustiveness.

Like Java enums, Swift enums can have methods and computed properties, and they can also conform to protocols and have static members. The method here reaches the case's own rawValue. Because Swift enums are value types with full method support and associated values, they replace many small class hierarchies a Java codebase would otherwise need.

Swift's error handling resembles Java's try/catch, but errors are values conforming to the Error protocol (an enum here, not a class hierarchy), and you mark each throwing call with try so propagation is visible at every site. The block is do { } catch { }, and catch can pattern-match specific cases. Unlike Java, Swift has no checked exceptions across the whole call graph — see the next note.

A Swift function is simply throws or not — it never declares which error types it throws, so there is no checked-exception bookkeeping rippling through every signature. Any conforming Error can be thrown, and callers either try within their own throwing function or handle it. This removes the "declare-or-catch" friction Java programmers know well, while still forcing errors to be acknowledged with try.

try? turns a throwing call into an optional — the value on success, nil on any thrown error — which is exactly the Java idiom of wrapping a call in try/catch and returning null on failure, compressed to one keyword. Its sibling try! asserts the call cannot fail and crashes if it does; reserve it for cases where an error is logically impossible.

Swift generics look much like Java's — a type parameter <T> with a constraint — but the constraint is a protocol (T: Comparable) that enables the actual > operator, rather than Java's T extends Comparable<T> plus compareTo. Crucially Swift generics are reified: the concrete type is known at runtime and specialized, with none of Java's type erasure.

A generic Swift type declares its parameter as Stack<Element> and can be a value type — a generic struct — which Java cannot express, since Java generics are class-based and erased. Because the element type is reified, a Stack<Int> stores unboxed Int values, avoiding the boxing that Java's Stack<Integer> forces.

Swift constrains a type parameter to a protocol (T: Equatable gives the == operator), and for richer requirements a where clause can constrain associated types — for example where Element: Comparable, Element == Other.Element. This expresses relationships between multiple type parameters that Java's bounded wildcards (? extends) struggle to capture.

Swift extensions add methods and computed properties to any type, including built-ins like Int and String and types you do not own. Java cannot do this — utilities live in static helper methods (isEven(value)) instead of reading as 4.isEven. Extensions cannot add stored properties, but otherwise let you grow an API where it naturally belongs.

Beyond extending other people's types, Swift programmers use extensions to organize their own types — splitting a type's stored properties, its conformance to each protocol, and groups of related methods into separate extension blocks (often across files). This keeps a large type readable in a way Java's single monolithic class body does not encourage.

An extension can make an existing type — even one from the standard library — conform to a new protocol after the fact, optionally constrained (here only arrays of Int). Java has no equivalent: you cannot retrofit an interface onto a type you do not control. This "retroactive modeling" lets Swift adapt existing types to new abstractions without wrappers or adapters.