Java.CodeCompared.To/Scala

Every runnable Scala program requires a main method on an object. println in Scala is available without a prefix — it comes from the automatically imported Predef object. Unit is the return type for methods that produce no meaningful value, equivalent to Java's void.

print writes without a trailing newline; println adds one. Both behave identically to Java's System.out.print and System.out.println. Semicolons are optional in Scala — newlines serve as statement separators.

Scala's printf and .format mirror Java's System.out.printf and String.formatted. For most cases, prefer Scala's s-interpolation (s"Name: $name") or f-interpolation (f"Score: $score%.1f"), which are more concise and type-safe.

Scala uses the same comment syntax as Java. Scaladoc uses /** ... */ with @param, @return, and @tparam (for type parameters) tags. Unlike Java, comments in Scala are often lighter — expressive types and names reduce the need for explanatory comments.

val in Scala corresponds to Java's final — the binding cannot be reassigned. The key difference is philosophy: Scala treats immutability as the default and discourages var. Java's var (Java 10+) infers the type but does not enforce immutability. In idiomatic Scala, mutable variables are rare.

Scala infers types throughout the language — local variables, generic type parameters, and method return types (when not public API). Unlike Java's limited var, Scala's inference works in more contexts and combines with immutability. Explicit types are still recommended in public method signatures for documentation and stability.

Scala's primitive types are capitalized: Int, Double, Boolean, Long, Float, Char, Byte, Short. Unlike Java, Scala has no distinction between primitive types and their boxed equivalents — the compiler handles boxing automatically where needed.

lazy val delays evaluation until first access, then caches the result permanently. Java has no built-in equivalent — developers use double-checked locking or Supplier<T> wrappers. lazy val is thread-safe in Scala: the first access initializes it exactly once. This is useful for expensive computations that may not always be needed.

Scala tuples are typed, immutable, and support up to 22 elements (Tuple1 through Tuple22). A tuple (10, "Alice") has type (Int, String). Tuple destructuring via pattern matching is the idiomatic way to unpack values. Java has no built-in tuple — use record for named fields or an array for homogeneous elements.

The s"" prefix activates string interpolation, allowing $variable and ${expression} directly in the string. This is far cleaner than Java's string concatenation or String.formatted. Any Scala expression can appear inside ${...}.

Scala strings are Java strings (java.lang.String), so all Java String methods work. By convention, zero-argument methods may be called without parentheses in Scala: text.length is equivalent to text.length(). Scala also adds extra methods to String via implicit conversions in StringOps.

Scala's triple-quoted strings preserve all whitespace literally — use stripMargin with the | prefix character to align multi-line content cleanly. Java 15+ text blocks normalize indentation automatically. Both approaches work; Scala's stripMargin is more explicit. Triple-quoted strings can also contain interpolation with the s prefix: s"""Hello, $name""".

The f"" interpolator is Scala's type-safe printf — format specifiers follow the variable reference with %. Unlike printf, the types are checked at compile time: f"$pi%d" is a compile error because pi is a Double, not an Int. Use s"" for simple embedding and f"" when numeric formatting is needed.

Array indexing in Scala uses () instead of [] — arrays are objects with an apply method, so parts(0) is syntactic sugar for parts.apply(0). For joining sequences, mkString on a collection is more idiomatic than String.join. All Java String methods (strip, split, replace, etc.) work identically.

Scala's List is an immutable singly-linked list — "modifications" return a new list. :: prepends efficiently (O(1)); :+ appends less efficiently (O(n)). For frequent appending, prefer Vector. Java's List.of() is also immutable but uses index-based get(i); Scala uses list(i) syntax (the apply method).

Scala's Vector is the default choice for indexed sequences — it offers near-O(1) random access, prepend (+:), and append (:+) via persistent data structure techniques. Unlike List, Vector supports efficient indexed access. Java's ArrayList is mutable; Scala's Vector returns a new collection for every "modification".

Scala's immutable Map uses -> to create key-value pairs (shorthand for Tuple2). map("key") throws NoSuchElementException if absent — use getOrElse for safe access, or get which returns Option[V]. The + operator returns a new map with the entry added; - returns one with a key removed.

Scala's immutable Set supports set operations: + (add element), - (remove), & (intersection), | (union), &~ or -- (difference). Each operation returns a new Set. Java's Set operations like retainAll are destructive; Scala's are pure.

Mutable collections in Scala require an explicit import from scala.collection.mutable. The immutable equivalents are always in scope by default — Scala's design makes immutability the path of least resistance. ArrayBuffer is the equivalent of Java's ArrayList: indexed, resizable, O(1) amortized append. The += and -= operators modify the buffer in place.

In Scala, if/else is an expression that returns a value — there is no ternary operator because if already serves that role. Java's if is a statement; to use it for an assignment without a mutable variable, you need Java's ternary (?:). The Scala version eliminates the mutable intermediate variable entirely.

Scala has no ++ or -- operators — use += 1 and -= 1 instead. The while loop requires a mutable variable, which is idiomatic but rare in functional Scala code. For iteration over known bounds, prefer ranges with for or recursive functions.

Scala's for uses <- (a generator) to iterate over any iterable — ranges, lists, sets, etc. 1 to 5 is inclusive; 1 until 5 excludes the upper bound. Scala has no C-style three-part for loop. The for is syntactic sugar for foreach, flatMap, map, and filter calls.

Scala's match expression replaces Java's switch. Like Java 14's switch expressions, match returns a value. The _ wildcard matches anything, like Java's default. Scala's match is far more powerful — it supports type matching, destructuring, guards, and collection patterns, all covered in the Pattern Matching section.

In Scala's match, the | operator combines multiple patterns in a single case. Binding a name (like other) instead of _ captures the matched value for use in the result expression. Java's switch uses commas to combine cases; Scala uses |. The captured name can be used in guard conditions too.

Scala's type pattern case x: Type both checks the type and binds the value — making the cast implicit. Java 16+ added similar syntax (instanceof Integer number), but only inside if chains, not in a unified match expression. Scala's approach is more composable: all type tests, bindings, and guards coexist in one construct.

Scala case classes support deep destructuring in match — nested structures are unpacked in one expression. Java 21's record patterns offer similar nesting, but only with records and in instanceof/switch. Scala's pattern matching predates Java's by over a decade and integrates with guards, sealed-type exhaustiveness checking, and collection patterns.

Pattern guards add an if condition after a case pattern. The variable bound by the pattern (s here) is available in the guard condition. Java's switch does not directly support range guards — you need integer division tricks or nested if statements. Scala's guards work with any pattern and any boolean expression.

Tuple matching in Scala destructures all elements simultaneously. Java has no native tuple type or matching support — this logic requires chained if/else on separate variables. The Scala version matches on the structure of the data directly, making the intent explicit and the code more compact.

Scala's :: is both the list cons constructor and a pattern: head :: tail matches any non-empty list, binding head to the first element and tail to the remainder. Nil matches an empty list. This eliminates index-based access that characterizes Java list processing. Java has no equivalent list pattern matching.

Scala method syntax uses def with the return type after a colon. Single-expression methods omit braces and return — the last expression is automatically returned. Scala discourages explicit return statements. Methods on an object are the equivalent of Java's static methods.

Scala supports default parameter values directly — no overloading needed. Java developers often write multiple overloaded methods just to provide defaults, which scatters the logic. Scala's approach reduces boilerplate and makes the default values explicit in one place. Default values can appear for any parameter, not only the last one.

Scala named arguments let callers specify parameters by name, allowing any order. This eliminates the common Java bug of passing arguments in the wrong order — especially for methods with multiple parameters of the same type (like three int values for year, month, day). Java has no named argument support; all calls are positional.

Scala varargs use Type* (vs Java's Type...). The numbers.sum call uses the built-in sum available on numeric sequences. To expand a collection into varargs, use the : _* splice syntax — equivalent to Java's array spreading, but works on any Seq, not just arrays.

Scala methods can have multiple parameter lists. This enables currying (partial application), improves type inference for generic parameters, and allows the last parameter list to serve as a block argument (for DSL-style APIs). Java achieves currying only through explicit Function<A, Function<B, C>> chaining or wrapping, which is verbose.

Scala function types use A => B (single argument) or (A, B) => C (two arguments). Unlike Java's many functional interfaces (Function, BiFunction, Predicate, Supplier, etc.), Scala uses a unified FunctionN hierarchy. Calling a function value uses () directly — no .apply() needed, though it works too.

Scala collections have map, filter, and other higher-order methods directly — no .stream() or .collect() wrapping needed. The _ placeholder is shorthand for a single lambda argument: _ * 3 means x => x * 3. Operations return the same collection type: List.map returns List, Vector.filter returns Vector.

foldLeft takes an initial value and a binary function, combining them left to right. The _ + _ shorthand means (acc, element) => acc + element. Scala collections have built-in sum, product, min, and max for numeric types. mkString joins elements with a separator, far simpler than Java's Stream reduce workaround.

Scala converts methods to function values with the _ suffix (doubleIt _). Methods can also be passed directly where a function is expected — Scala performs automatic eta expansion. Java uses :: method references (Main::doubleIt). In Scala, def defines a method; val f: Int => Int = ... defines a function value — they differ in subtle ways for advanced use.

Scala case classes are similar to Java records but predate them by many years. Key differences: no new keyword needed (the companion object's apply handles construction), field access without parentheses (person.name not person.name()), and built-in toString, equals, hashCode, and copy. Case classes integrate seamlessly with pattern matching.

The copy method is auto-generated for every case class, creating a new instance with specified fields changed and others unchanged. Java records require manually written withX / withY methods for this pattern. copy is essential for "update" operations on immutable data — it is the functional equivalent of setters.

Scala's == calls equals — for case classes this is structural equality comparing all fields. Java's == is always reference equality; you must use .equals() for value comparison. In Scala, use eq for reference equality (rarely needed outside of performance-critical code). Java records also implement structural equals, so the behavior is similar.

Sealed traits + case classes form Scala's algebraic data types (ADTs). The compiler verifies that all cases in a match are covered — if you add a new case class extending the sealed trait, every incomplete match is flagged. Java 17+ sealed interfaces with records provide a similar feature, inspired by Scala's design. Exhaustiveness checking prevents entire categories of runtime bugs.

This is Scala's idiomatic way to model computations that can succeed or fail. The +T covariance annotation means Result[Dog] is a Result[Animal]. Result[Nothing] for Err lets it be used where any Result[T] is expected — since Nothing is a subtype of everything. Java's generics are invariant, requiring Err<T> instead.

Scala traits are more powerful than Java interfaces — they can have abstract members, concrete methods, fields, and state. Java's default methods (Java 8+) are a subset of what traits have always supported. Traits are the primary mechanism for code reuse and polymorphism in Scala. The keyword override is required (not optional) when overriding a member.

Scala uses extends FirstTrait with SecondTrait with ThirdTrait for mixin composition. Unlike Java's implements, Scala traits can hold mutable state. Scala resolves diamond-inheritance issues through linearization — a deterministic method resolution order. Traits can also be mixed in at instantiation time: new UserService() with ExtraLogger.

Scala abstract classes work like Java's — they can have abstract methods and constructor parameters, but cannot be instantiated directly. Constructor parameters become val fields automatically when declared with val. For code sharing in Scala, prefer trait over abstract class; use abstract class only when you need constructor parameters or Java interoperability.

Scala requires the override keyword — omitting it is a compile error. This prevents accidental overriding when a base class adds a new method that happens to match a subclass method name. Java's @Override annotation is optional and produces only a warning if absent. Scala's approach catches an entire class of subtle bugs at compile time.

When a companion object defines apply(...), the class can be called like a function: Celsius(100) calls Celsius.apply(100). This is how all Scala case classes and collection constructors work. Java's static factory methods like Celsius.of(...) are the closest equivalent. The apply pattern creates natural construction syntax without new.

Option[T] is Scala's built-in equivalent of Java's Optional<T>. Some(value) wraps a value; None represents absence. Unlike Java's null, None is a proper value with a type — you cannot accidentally call methods on it. The Scala convention is to never return null from a public API — use Option instead.

getOrElse extracts the value or returns the default. orElse returns the Option itself or an alternative Option. Both accept lazy arguments via Scala's call-by-name semantics: empty.getOrElse { expensiveComputation() } runs only when the Option is None. Java's orElseGet uses a Supplier for the same purpose.

Option is a monad: map transforms the value inside a Some, leaving None unchanged. flatMap chains operations that themselves return Option, preventing nested Some(Some(...)). This is the foundation of for comprehensions — for { a <- optA; b <- optB } yield f(a, b) desugars into flatMap/map chains.

Scala's Map.get returns Option[V] — not the value directly. This forces you to handle the missing-key case. Pattern matching on Some/None is explicit; getOrElse is more concise for simple defaults. Java's Map.get returns null for missing keys — a common source of NullPointerException bugs.

Scala's try/catch/finally uses match-style case syntax inside the catch block. This allows matching on specific exception types and adding guards. Unlike Java, Scala has no checked exceptions — all exceptions are unchecked. The compiler never forces you to declare or handle them, reducing boilerplate but requiring discipline.

Try[T] wraps a computation that may throw, returning Success[T] or Failure(exception). Unlike Java's try/catch (a statement), Try is a value you can pass around, map over, and chain. Try(expr) captures any non-fatal exception thrown by expr. This makes error handling composable — map over a Success and errors propagate through Failure.

Either[L, R] represents a value that is either a Left (by convention: an error) or a Right (a success). Unlike Try, Either allows a typed error value — Left can be any type, not just Exception. Java has no built-in Either; developers use custom sealed types or third-party libraries.

Scala throw is an expression with type Nothing — it can appear anywhere an expression is expected, including as the else branch of getOrElse. Custom exceptions extend Java exception classes directly. Scala has no checked exceptions — the compiler never forces you to declare or catch them, which reduces boilerplate but requires careful API design.

Scala's for { ... } yield ... is a for comprehension — syntactic sugar for chained flatMap, filter, and map calls. Each if guard becomes a .filter. This is far more readable than Java's Stream chain for multi-filter transformations. Without yield, the comprehension uses foreach and returns Unit.

Multiple generators in a for comprehension produce a Cartesian product — this desugars to nested flatMap calls. Java's equivalent requires explicit flatMap with a nested stream, which is verbose and harder to read. For comprehensions scale cleanly to any number of generators and filters, remaining readable at any depth.

For comprehensions work over Option, List, Try, Either, and any monadic type. When a generator <- produces None, the entire comprehension short-circuits to None — no explicit flatMap chaining needed. The = domain line assigns a value without unwrapping (no <-). Java requires explicit .flatMap chaining with Optional.

Inside a for comprehension, = expression creates an intermediate binding without a generator — the value is computed once per outer iteration. This corresponds to a .map step in the desugared form. The comprehension then applies the guard (if) to filter based on the computed value. Unlike Java streams, the computation order is explicit in the for block.

In Scala there are no static members — everything that is "static" in Java becomes a member of the companion object (a singleton object with the same name as its class, in the same file). The companion object and the class can access each other's private members. Java static methods and fields translate directly to companion object methods and vals.

A companion object's apply is called when you write Email("...") without new. The constructor is private in the class, but the companion can call it — companions share access. This pattern lets the factory return an Option, encapsulating validation. Java static factories like Email.of(...) are the closest equivalent.

The unapply method on a companion object is the "extractor" — it enables a class to participate in pattern matching, just like case classes. unapply returns Option[(A, B)] for successful matching. Java 21+ enables similar destructuring via record patterns, but only for records. Scala's extractors work on any class and can implement complex matching logic.

Every Scala object is a singleton — exactly one instance exists per JVM. No getInstance(), INSTANCE, or double-checked locking is needed. Java's singleton patterns (enum singleton, static holder idiom) exist to compensate for a language feature Scala provides natively. Scala object singletons are initialized lazily on first access and are thread-safe.