Swift.CodeCompared.To/Java

Read the incantation left to right and it is all necessary in Java's model. public lets the launcher, which is outside your class, call it; static means no instance has to exist first; void means the exit status comes from System.exit rather than a return; String[] args is CommandLine.arguments.dropFirst(). JEP 445 is relaxing this for single-file programs, but every codebase you will meet writes it out.

A string template feature was previewed in Java 21 and 22 and then withdrawn — do not plan around it. Note %n rather than \n: it emits the platform line separator, and printf adds nothing on its own. The compiler turns a chain of + into an efficient concatenation, so the old advice to reach for StringBuilder applies only inside loops.

A class with no toString prints something like Point@6d06d69c — the class name and an identity hash — which is the Java equivalent of a useless default and the reason record is such a relief. There is no separate debugDescription; one method serves both purposes. Collections print their elements by calling toString on each, so a list of records reads well for free.

Swift prints 1 and Java prints 99, and no amount of care with final changes that. There is no struct, no copy-on-write, and no way to declare "this type has value semantics" — Project Valhalla's value classes are still not shipped. What you get instead is a discipline: make the type immutable so aliasing cannot be observed. That is what the next row is about, and it is the habit to adopt on day one.

That last sentence is the whole trick, and it is why records should be your default for data on the JVM. Note two things Swift gives you that a record does not. There is no memberwise with-style copy: changing one field means new Point(first.x(), 99), spelled out. And the accessor is point.x(), a method, not a field — a record's components are private and final underneath. Swift's == becomes equals; == in Java is identity, which the strings section returns to.

This is the single most common encapsulation bug on the JVM, and it is invisible if you are reading with Swift eyes. The three defences, in order of preference: store and return an immutable collection (List.of, List.copyOf, which throw on mutation); return Collections.unmodifiableList(items), a live read-only view; or copy on the way out, as safeItems does. The same applies to arrays and to any mutable object you expose — including one you accept in a constructor, which should be copied on the way in.

So final List still accepts add, exactly as let on a Swift class reference would still allow its properties to change. Immutability in Java is a property of the type, never of the binding: List.of(...) is immutable, new ArrayList<>(...) is not, and no keyword at the use site can change that. Write final anyway — it documents intent and the compiler needs it for capture in a lambda.

That rules out inout, swap functions, and any method that reassigns a caller's variable. The workarounds are to return the new value (much the best), to mutate a field of a passed object as above, or to pass a one-element array, which you will meet in old code and should not write. Note that the same rule makes the aliasing danger asymmetric: a method cannot repoint your variable, but it can gut the list your variable points at.

So the compiler cannot help, and the failure arrives as a NullPointerException at the point of use rather than as an error at the point of the mistake. Since Java 14 the message names the expression that was null, which is a real improvement. Three things partly fill the gap and none of them is the language: Optional as a return type (the next row), nullability annotations that static analysers read (@Nullable, @NonNull — there are several competing packages), and Kotlin, which is the JVM language that did fix it.

An Optional is itself a reference and can be null, which is the joke that writes itself. The official guidance is narrow and worth following: use it as a return type, and not for fields, parameters or collection elements — it costs an allocation, it does not serialise well, and Optional<List<T>> where an empty list would do is a smell. orElse is ??, orElseGet takes a lambda for an expensive default, and get() is the force-unwrap you should almost never write.

Optional.ofNullable is the bridge from a possibly-null reference into the chain, and map short-circuits on empty exactly as ?. does. It costs an allocation per step, which matters in a hot loop and nowhere else. The alternative you will meet more often in real code is if (order != null && order.customer() != null && ...), which is why the nullability of every link ends up in your head rather than in the types.

The early-return shape survives — it is just if with a return, and Java has no else requirement to enforce it. The bindings do not: a variable bound inside a try block is not in scope after it, which is why number is declared first. And Integer.parseInt throws where Int(raw) returns nil, so the parse becomes exception handling — the running theme that Java uses exceptions where Swift uses optionals.

So the idiom is a static factory method — conventionally named of, from or valueOf — with the constructor kept private or package-private. That has advantages Swift's initializers do not: a factory may return a cached instance or a subclass, and it may have a name that says what it does. A record can also validate in a compact constructor (record Percentage(int value) { Percentage { if (value < 0) throw new IllegalArgumentException(); } }) when throwing is the right answer instead of an empty Optional.

So final var name = "Ada" is legal and is the closest spelling of let. var works only for local variables with an initialiser — not for fields, parameters or return types — which keeps it from spreading the way inference does in Swift. And note the numeric literal: double typed = 3 compiles because Java widens int to double implicitly, where Swift would demand 3.0 or a conversion. Java's implicit numeric conversions are wider than Swift's in every direction that does not lose information.

Each primitive has a matching boxed class (int/Integer, double/Double, boolean/Boolean) and the compiler converts between them silently. Two traps follow. Unboxing a null Integer into an int throws a NullPointerException from a line that looks like arithmetic. And == on two Integers compares references — it happens to work for small values because −128 to 127 are cached, which makes the bug appear only in production. Compare boxed numbers with equals, always.

So Long.MAX_VALUE + 1 is Long.MIN_VALUE, with no exception and no warning — the same behaviour as Swift's &+, applied to every arithmetic expression in the language. The Math.*Exact family (addExact, multiplyExact, toIntExact) throws ArithmeticException instead and is what you want anywhere a number could be attacker-influenced. BigInteger is the arbitrary-precision escape hatch.

Before records this was genuinely painful — a whole class, or Map.Entry, or an array of Object. A record makes it one line, and the result is better than a tuple: the components have names that survive into the caller and into the debugger, and the type is documentation. There is no destructuring at the call site, though a record pattern in a switch or instanceof gets close: if (result instanceof DivisionResult(int quotient, int remainder)).

It is the first Java bug nearly everyone writes, and it is worse than a plain failure because it often works: identical string literals are interned into one object, so "hello" == "hello" is true and the same comparison on a string that came from a file or a network is false. Always equals, and Objects.equals(a, b) when either might be null. The same rule applies to every type: == is identity unless you are comparing primitives.

A Java String is a sequence of UTF-16 code units, so length() counts units, not characters: "naïve" is 5 because ï fits in one unit, but any emoji outside the Basic Multilingual Plane counts as 2 and substring can split it in half. Swift's String.Index exists precisely to make that impossible. When correctness matters use codePointCount, codePoints(), or java.text.BreakIterator for grapheme clusters. Also note substring(start, end) takes an end index, not a length.

The margin is set by the least-indented line or the closing delimiter, whichever is further left — the same rule Swift uses for its closing """. One difference to watch: a Java text block keeps the trailing newline before the closing delimiter, which is why this example uses print rather than println; put the closing """ on the same line as the last character to drop it, or end the line with \. There is no interpolation, so formatted(...) is the usual companion.

Java's split takes a regular expression, not a literal separator — so splitting on "." or "|" silently gives you nothing useful until you escape it (split("\\.")) or use Pattern.quote. It also drops trailing empty strings unless you pass a negative limit. String.join puts the separator first, the reverse of Swift's joined(separator:), and Collectors.joining is the streams version with optional prefix and suffix.

Swift prints 4 for the copy; Java prints 5, because copy is the same list. A real copy is new ArrayList<>(numbers) and is shallow. Note the interface-versus-implementation habit: declare the variable as List and construct an ArrayList, so callers depend on the contract rather than the class. List.of(...) builds an immutable list and is the right default when nothing needs to change; it throws UnsupportedOperationException on add, which is a run-time answer to a question Swift settles at compile time.

Swift returns an Optional from a subscript; Java's get returns null, so getOrDefault is the safer everyday call and containsKey answers the membership question. The implementations differ in ordering, which Swift's single Dictionary hides: HashMap has no order at all, LinkedHashMap keeps insertion order, and TreeMap — used here — keeps keys sorted, so the loop needs no explicit sort. Also useful: computeIfAbsent, which builds a value in place and replaces the read-check-write dance.

A stream is lazy and single-use, which makes it closer to Swift's lazy view than to a plain array chain — reusing one throws IllegalStateException. Collecting back to a list is .toList() (Java 16+) or .collect(Collectors.toList()). For numbers, mapToInt gives you an IntStream with a real sum() and no boxing, which is worth reaching for. The Swift equivalents that have no stream counterpart are the free-standing operators: there is no zip and no enumerated() in the standard library.

Comparator.comparing(Person::name) is the general form, with comparingInt/comparingDouble avoiding boxing, .thenComparing(...) chaining a tie-breaker, and .reversed() flipping it — a small combinator language that ends up more readable than a hand-written closure once there are two keys. List.sort mutates in place and needs a mutable list; the stream version above copies. Both are stable.

For a plain Java class you must override equals and hashCode together, and the contract is unforgiving: equal objects must have equal hash codes, or the object goes into a HashMap and is never found again. That is the strongest practical argument for making value-shaped types records. One more rule with no Swift counterpart: mutating a field that hashCode reads, after the object is in a set, loses it — which is another reason those types should be immutable.

There is no range type and no enumerated(), so an index-and-value loop is the counted form — IntStream.range(0, list.size()) exists but reads worse for this. break and continue work as expected, and Java adds labelled versions (outer: for (...) { ... continue outer; }) that let you jump out of nested loops, which Swift also has. What Java does not have is where clauses on a loop, or for case let.

With -> there is no fall-through and no break, several labels can share an arm, and the whole thing is an expression that produces a value. What is missing is ranges: case 400...499 has no counterpart, so a range test becomes an if chain or a switch (true)-style guard. Swift's where clause does exist, as case Integer number when number > 100 ->, but only in a pattern arm — the enums section shows it.

Try-with-resources is the better analogue because it ties the cleanup to the resource rather than to the line you happened to write it on, and it closes several resources in reverse order of acquisition, exactly as stacked defers unwind. Where defer is doing something that is not a resource — restoring a flag, logging on exit — finally is the direct translation. Neither is a substitute for deinit, which the memory section covers.

That is the standard idiom and it has real costs — the combinations multiply, and two overloads that differ only in an int cannot express which int a caller meant, as the second call above quietly demonstrates. For more than about three optional values the idiom shifts to a builder, or to a parameter object (a record). What Java does have is varargs: void log(String... parts) accepts any number and receives an array.

The workaround is to capture a mutable object rather than a mutable variable: an AtomicInteger, a one-element array, or a field. This is the same restriction that makes Java's lambdas cheap — captured values are copied into the lambda object — and the reason there is no [weak self] to write: a lambda that captures this keeps the enclosing object alive, and the garbage collector deals with the cycle.

So (Int) -> Int has no single spelling: it is Function<Integer, Integer> if you accept boxing, IntUnaryOperator if you do not, or an interface of your own. The java.util.function package holds forty-odd of these, and the naming is systematic once you see it: Function takes one and returns one, BiFunction two, Supplier none, Consumer returns nothing, Predicate returns boolean, and an Int/Long/Double prefix means the primitive version. The method name differs per interface — apply, get, accept, test — which is the part that feels arbitrary.

There are four forms and they are worth recognising: Type::staticMethod, instance::method, Type::instanceMethod (where the first argument becomes the receiver — that is what String::toUpperCase is doing), and Type::new for a constructor. What Java does not have is trailing-closure syntax, so the lambda always sits inside the parentheses, and there is no shorthand for the parameter: $0 must be given a name.

This is one of the genuinely bigger losses coming from Swift, and it explains a great deal of Java's shape: Collections.sort(list), Arrays.asList(array), Objects.requireNonNull(value) and the whole StringUtils genre exist because the methods could not live on the types. It also means retroactive conformance is impossible — you cannot make a third-party class implement your interface, which the protocols section returns to. Kotlin's extension functions are the JVM answer, and they compile to exactly the static methods above.

What Swift has and Java does not: default parameter values (hence the delegating constructor, calling the other with this(...)), and private(set), which becomes a private field plus a public accessor. What Java has and Swift does not: a compiler that insists every final field is definitely assigned by the end of every constructor, which is the same guarantee Swift's two-phase initialisation gives, checked differently. There is no convenience init distinction and no required init.

So the discipline moves to you: mark a class final when it is not designed for extension, which is most of them. @Override is an annotation rather than a keyword, and it is optional — omit it and a misspelled method name silently becomes a new method instead of an override, which is exactly the bug Swift's mandatory override prevents. Write it every time; every IDE and linter will insist. super.speak() works as expected, and there is no multiple inheritance.

A Java nested class is inner — holding a hidden reference to the enclosing instance — unless you mark it static. Records, enums and interfaces nested in a class are implicitly static; a plain class Snapshot would not be, and that hidden reference is a classic memory leak and the reason new Outer.Inner() needs an outer instance. Always write static on a nested class that does not need its enclosing object. Java's static members are also not inherited-and-overridable the way Swift's class var is.

The getX/setX naming is the JavaBeans convention, and it is not merely cosmetic — frameworks (Jackson, JPA, Spring) discover properties by that naming, so departing from it changes behaviour. Records use the shorter accessor form (point.x()) instead, which is now the preferred style for new value-shaped types. There is no willSet/didSet, no lazy var (write the null-check yourself, or use a holder), and no property wrappers.

Three differences to hold on to. Conformance must be declared at the type's definition, so you cannot make someone else's class implement your interface: retroactive conformance is impossible, and that is a real loss. An interface may not hold stored state, so a protocol extension that adds a property has no counterpart. And implementing methods must be public — every interface member is public, which is why Square's methods carry the modifier while the record's own accessors do not need it stated.

Where they part company is dispatch. A method declared only in a Swift protocol extension is dispatched statically, so a conforming type's own version is ignored when the value is held as the protocol — the notorious gotcha. A Java default method is always virtual: an implementing class's override wins, whatever the static type. So Java is simpler here, and the Swift habit of checking whether a method is in the protocol requirement list has nothing to check. Interfaces may also hold static methods and public static final constants.

For this shape the translation is exact and arguably simpler — no where clauses, no Self requirements, and a Container can be used as a variable type directly. What you lose is everything some and any were invented for. There is no opaque return type, so a method cannot promise "some Container without saying which"; and there is no distinction between a protocol used as a constraint and as an existential, because Container<String> is always usable as a type. Java's cost shows up instead in the wildcard syntax of the next row.

So <, > and + can never be given a meaning for your type, and every comparison reads as compareTo(...) < 0. Comparable is the natural ordering built into the type; a Comparator is an ordering supplied from outside, which is the more flexible and more common tool. The contract that matters: compareTo returning zero should agree with equals, or a TreeSet and a HashSet will disagree about what the same collection contains.

Every interface-typed reference is an existential, dispatched through a method table, and the compiler never specialises. That removes a whole category of decision and a whole category of performance tuning: there is no way to say "this returns one concrete type" and no @inlinable-style escape. In exchange, the errors Swift raises about protocols with Self or associated-type requirements not being usable as types simply do not exist — a generic interface can always be a variable type, at the cost of a wildcard when the parameter is unknown.

Because the cases are singletons, == is the correct comparison here — the one place in Java where reference equality is idiomatic. A raw value is a field you declare yourself; valueOf looks a case up by its name and throws when there is no match, so the closest thing to Swift's failable init(rawValue:) is a static lookup you write. A switch over all cases of an enum needs no default, and adding a case later turns every such switch into a compile error — which is the exhaustiveness Swift gives you.

The switch above needs no default, and adding a third permitted type makes it fail to compile until you handle it. That is real exhaustiveness, not a convention. The differences from Swift are in the ergonomics rather than the guarantee: each case is a separate top-level type rather than a case of one, so you write three declarations instead of one enum; and there is no dot-shorthand, so .circle(radius: 1) becomes new Circle(1). Sealed types can also permit classes, and the permitted types must live in the same package or module.

Even the guard survives, spelled when rather than where. Patterns nest, so case Order(Customer(String name), _) reaches two levels down. Two things Swift still has that Java does not: if case as a standalone statement (Java's instanceof pattern covers the common case — if (shape instanceof Circle(double radius))), and value patterns over ranges. Note that a bare type pattern (case Rectangle rectangle) and a record pattern can be mixed freely.

The bound variable is in scope wherever the test is known to have succeeded, including the rest of an && chain and the body of an early return's opposite branch — the compiler tracks it by flow. Without the pattern you get the old form, ((String) value).length(), which throws ClassCastException where as! would trap. There is no as? expression that yields an optional, so a cast is always a test followed by a use.

Constraints are spelled <Element extends Comparable<Element>> — extends for both classes and interfaces, with & to require several. There is no where clause of Swift's expressiveness and no way to constrain an associated type, because there are none. Inference at the call site works much as Swift's does, and the explicit form is Main.<String>firstOrDefault(...), which you will rarely need and never enjoy.

So a List<String> and a List<Integer> are the same class at run time — both print ArrayList, and comparing the classes gives true, where Swift reports two different types. (The example constructs ArrayLists deliberately: List.of returns size-specialised classes, so a one-element list and a three-element list differ for a reason that has nothing to do with generics.) and the consequences are everywhere. You cannot write new Element[10], ask value instanceof List<String>, overload two methods that differ only by type argument, or catch a generic exception type. Where Swift can specialise a generic function per type, Java compiles one version that works on Object and inserts casts — which is also why a List<Integer> boxes every element. The escape hatch when a method genuinely needs the type is to pass a Class<Element> token as an argument.

? extends Number means "some unknown subtype of Number": you may read Numbers out and may not add anything in, because the compiler does not know which subtype the list actually holds. ? super Integer is the mirror image, for a list you will only write to. The mnemonic is PECS — Producer extends, Consumer super. Swift needs none of this for the example above, because a generic parameter accepts any concrete element type directly and the compiler specialises per type. The wildcard exists because Java's single erased implementation has to be told, at the signature, which direction the unknown type may flow. Recognising why it is there is most of the work.

So throws means almost exactly what you expect, do/catch is try/catch, and the compiler error for an unhandled failure is the same complaint in different words. The one syntactic difference is that Java has no try keyword at the call site — the call looks ordinary, and the compiler tracks what may throw — where Swift makes every fallible call visible. Java is also more specific: throws ConfigException, IOException lists the types, and a catch clause selects by type rather than by pattern.

That is where NullPointerException, IllegalArgumentException, IndexOutOfBoundsException and ArithmeticException live, and it is closest to Swift's fatalError/precondition — with the crucial difference that it is catchable and routinely is, at a request boundary or a thread's top level. The convention is: checked for what a caller can reasonably recover from, unchecked for programming errors. Opinion inside the Java world is genuinely divided about checked exceptions, and much modern code (and Kotlin, and most frameworks) uses unchecked ones throughout.

Converting an exception into an Optional is a try/catch written out, usually wrapped in a small helper the way parse is here — and doing it in a lambda inside a stream is genuinely awkward, because a checked exception cannot escape a Function. The nearest thing to try! is catching and rethrowing as an unchecked exception, which is what throw new RuntimeException(error) means when you see it, and what Optional.get() amounts to.

It is more verbose than Result and gives the same exhaustiveness, plus the freedom to name the cases after the domain rather than "success" and "failure". What it does not give you is the combinator vocabulary — no map, flatMap or get() unless you write them. This pattern is common in newer codebases and in functional-leaning libraries; a great deal of Java simply throws instead, and that is not wrong.

Java has finalize, which is deprecated for removal, and Cleaner, which is for safety nets rather than for cleanup you depend on — neither is guaranteed to run at all. So every resource is released explicitly: AutoCloseable plus try-with-resources is the pattern, and it is enforced by convention and by static analysis rather than by the language. The rule for someone arriving from Swift: if it has a close(), it belongs in the parentheses of a try.

This is the one place where the JVM's memory model is straightforwardly easier: parent pointers, delegates and closures capturing self need no annotation and leak nothing. WeakReference exists and is for caches and listener registries — cases where you want the collector to be able to reclaim something — not for breaking cycles. What replaces retain cycles as the leak to watch for is the long-lived collection: a static map or a listener list that nobody removes from keeps its contents alive for the life of the process.

A defensive copy in Java is an eager allocation and an element-by-element copy, every time — so the advice to copy on the way in and on the way out has a cost that Swift's does not, and it is one reason immutable collections (List.of, List.copyOf, and Guava's immutable family) are preferred: they can be shared freely because nobody can change them. List.copyOf is also smart enough to return the argument unchanged when it is already immutable.

So asynchronous code is written in the callback style Swift left behind — thenApply, thenCompose (which is flatMap), thenCombine, exceptionally — and a chain of five reads much worse than five awaits. get() blocks the calling thread, which is exactly what you must not do on a UI thread and is fine in a main like this one. Java's actual answer to callback fatigue is not syntax but virtual threads: with a thread that is cheap to block, ordinary sequential code becomes the concurrent style, which the next rows cover.

A Swift task group is structured: the group cannot outlive its scope, a failure cancels the siblings, and cancellation propagates down. A list of CompletableFutures has none of that — cancelling one does not touch the others, and a future you forget about keeps running. CompletableFuture.allOf(...) waits for a whole array, and JEP 505's StructuredTaskScope brings genuine structured concurrency to Java, still in preview at JDK 25. This row does run in the browser, incidentally: three supplyAsync tasks share the common pool's single worker thread, so they complete one after another rather than at once.

The gap is enforcement, and it is the whole of Swift 6's strict concurrency: nothing in Java stops you reading total from another thread without the lock, and the compiler will not tell you that a field is shared. There is no Sendable, no data-race safety checking, and no compile error for capturing mutable state in a task. What Java offers instead is a well-stocked toolbox — synchronized, ReentrantLock, AtomicInteger, ConcurrentHashMap, the java.util.concurrent collections — and the discipline to use it.

total += 1 is a read, an add and a write, so two threads interleave and updates are lost — the printed total is usually well under 200,000 and varies between runs. (Shown rather than run: the servers that run the Java here allow only one thread beyond main, and losing an update takes two.) Nothing in Java warns you: not the compiler, not the type system, not a runtime check. The fixes are synchronized, an AtomicInteger, or not sharing the variable.

The consequence is the opposite of Swift's: rather than marking functions async and awaiting, you write ordinary blocking code and let the runtime unmount the virtual thread while it waits. No colouring, no await, no separate ecosystem of async libraries — the existing blocking ones become efficient. The catch is that blocking inside a synchronized block pins the carrier thread, which JDK 24 largely fixed. Underneath, a virtual thread costs two real threads: a carrier to run it and an unblocker to wake it — which is one more than the servers that run the Java here allow, so this example is shown rather than run.

Maven is declarative XML with a fixed lifecycle and is common on the backend; Gradle is a programmable DSL and is what Android uses, so an iOS developer sent to Android will meet Gradle first. Both resolve from Maven Central, both cache in ~/.m2 or ~/.gradle, and neither has a lockfile by default — versions are pinned in the build file, and transitive resolution picks the nearest version, which is the source of most "it works on my machine" on the JVM. There is no equivalent of Xcode as the single blessed editor: IntelliJ, Eclipse and VS Code all work.

A Java annotation is metadata that survives into the class file, and reflection lets code inspect classes, read those annotations and call methods by name at run time. That is how JUnit discovers tests, how Spring wires dependencies, how Jackson maps JSON to fields, and how mocking libraries work — a whole style of framework that Swift's macros and property wrappers approach from the other direction. It also means these frameworks fail at run time rather than at compile time, and that erased generics and reflection together explain most of the JVM's configuration culture.