Ruby.CodeCompared.To/Java

Every Java program begins with a class — there is no top-level code as in Ruby. The entry point is always a method called main with the exact signature public static void main(String[] args). Unlike Ruby's puts, Java uses System.out.println(). On Compiler Explorer the class must not be declared public because the filename is fixed to example.java.

Java has three comment styles: // for single-line, /* */ for multi-line, and /** */ for Javadoc. Javadoc comments document classes and methods and are processed by the javadoc tool to generate HTML API documentation — an important part of Java's ecosystem. Ruby's =begin/=end multi-line syntax is rarely used in practice; Java's /* */ is idiomatic.

Java requires every piece of code to live inside a class — there is no top-level code. Multiple non-public classes may appear in a single file. The this keyword is the Java equivalent of Ruby's self: it refers to the current instance and disambiguates between a parameter and a field of the same name. Constructor names match the class name exactly (unlike Ruby's initialize).

Java requires every variable to be declared with an explicit type. Where Ruby infers the type from the assigned value at runtime, Java must be told at compile time whether a value is a String, int, double, boolean, and so on. The type annotation serves as live documentation — a Java reader knows exactly what kind of data each variable holds without running the code.

The var keyword (Java 10+) tells the compiler to infer the variable's type from the right-hand side — the type is still fixed at compile time. This is syntactic sugar that reduces verbosity without sacrificing type safety. var is only allowed for local variables, not for method parameters, return types, or fields. Ruby's type inference operates at runtime; Java's var operates at compile time.

Java has eight primitive types that are NOT objects: byte, short, int, long, float, double, boolean, and char. In Ruby, even 42 is an Integer object with methods. Java primitives are stored directly on the stack for performance, but cannot be used as generic type parameters (List<int> is illegal) or stored in collections — their wrapper types (Integer, Double, etc.) must be used instead.

Java collections cannot hold primitive types — List<int> is illegal. Each primitive has an object wrapper: int ↔ Integer, double ↔ Double, boolean ↔ Boolean. Java automatically boxes primitives to wrappers when storing in collections (autoboxing) and unboxes them back when retrieved. A hidden danger: if a wrapper object is null and gets unboxed automatically, a NullPointerException is thrown.

The final keyword creates a variable that cannot be reassigned after initialization — enforced at compile time. For class-level constants, static final is the standard pattern, analogous to Ruby's constants. Unlike Ruby, where reassigning a constant produces only a warning at runtime, Java's final is an absolute guarantee: any attempt to reassign is a compilation error that prevents the program from building at all.

null in Java is the source of a large class of bugs — a NullPointerException at runtime is one of the most common Java errors. Unlike Ruby's nil, which is a proper object with methods like nil? and to_s, Java's null has no methods at all: calling any method on null throws immediately. Optional<T> (Java 8+) is the idiomatic solution for values that may be absent — it forces the caller to acknowledge the empty case, analogous to Ruby's safe navigation operator &..

Java distinguishes widening conversions (safe, automatic) from narrowing conversions (may lose data, requires an explicit cast with the target type in parentheses). Converting between strings and numbers requires the wrapper class methods: Integer.parseInt(), Double.parseDouble(), and Integer.toString(). There is no Ruby-style .to_i or .to_s method on primitives — the conversion is always explicit.

Java does not have string interpolation. The + operator concatenates strings and automatically converts non-string operands to strings via their toString() method. String.join() is a clean alternative for combining a list of values with a separator. Concatenating with + inside a loop is inefficient (creates a new object every iteration) — use StringBuilder for building strings incrementally.

String.format() and the newer .formatted() instance method (Java 15+) use the same format specifiers as C's printf: %s for strings, %d for integers, %.2f for floats with 2 decimal places. System.out.printf() prints without a trailing newline — use %n as a platform-appropriate line separator. The .formatted() method on string literals is the most idiomatic modern Java approach and directly parallels Ruby's format().

Text blocks (Java 15+) use triple-quote delimiters and automatically strip common leading whitespace, producing a clean multi-line string. They are the Java equivalent of Ruby's squiggly heredoc <<~. The closing """ determines the indentation baseline — any whitespace to its left is stripped from all lines. Text blocks are particularly useful for embedding JSON, SQL, HTML, or XML without escaping every double-quote.

Java strings are immutable objects — every operation returns a new String instance rather than modifying the original, exactly like Ruby's frozen strings. Method names differ slightly from Ruby: strip() (Ruby: strip), contains() (Ruby: include?), replace() (Ruby: gsub for literal replacement), toUpperCase() (Ruby: upcase). Note that Java method calls always require parentheses, even when there are no arguments.

This is one of the most common Java gotchas: == on objects compares memory addresses (references), not values. Two different String objects with identical content return false for ==. Always use .equals() to compare string content. String literals from the same intern pool may coincidentally return true for ==, which masks the bug — using new String(...) exposes it clearly. Ruby's == on strings always means value equality.

Because Java strings are immutable, concatenating with + inside a loop creates a new object on every iteration — O(n²) in memory allocations. StringBuilder maintains a mutable internal buffer and produces the final string only when .toString() is called, making it O(n). For thread-safe contexts, use StringBuffer instead. Ruby's array-join pattern (array.map { ... }.join(", ")) is clean and idiomatic; in Java, StringBuilder or a stream Collectors.joining() are the equivalents.

Java arrays have a fixed size set at creation time — they cannot grow or shrink like Ruby arrays. The length property (no parentheses — it is a field, not a method) returns the element count. Printing an array with System.out.println(scores) gives a cryptic reference like [I@1b6d3586 — Arrays.toString() is required for a readable representation. For most purposes, ArrayList<T> is preferred over raw arrays in modern Java.

ArrayList<T> is the Java equivalent of a Ruby array — dynamically sized and ordered. The type parameter <String> enforces that only strings can be added, caught at compile time. In modern Java, List<T> is the preferred interface type for variables and parameters; ArrayList<T> is the most common concrete implementation. Note size() (a method call, with parentheses) vs Ruby's length or size. Wrapping List.of() in new ArrayList<>() makes the list mutable.

HashMap<K,V> is the Java equivalent of a Ruby hash. Pairs are added with .put(), retrieved with .get(), and tested with .containsKey(). Unlike Ruby hashes (which preserve insertion order since Ruby 1.9), HashMap does not guarantee any ordering — use LinkedHashMap for insertion-order preservation or TreeMap for sorted keys. forEach with a lambda is the idiomatic way to iterate key-value pairs.

HashSet<T> stores unique values with no guaranteed ordering — the Java equivalent of Ruby's Set. Adding a duplicate silently does nothing. The contains() method tests membership in O(1) average time. For ordered unique values, use TreeSet<T> (sorted by natural order) or LinkedHashSet<T> (insertion order). Set.of() (Java 9+) creates an immutable set literal, analogous to Ruby's Set[...].

List.of(), Map.of(), and Set.of() (Java 9+) create immutable collections that throw UnsupportedOperationException on any mutation attempt. They are null-hostile — no null elements or keys allowed. These are the Java equivalent of .freeze in Ruby. Prefer these factory methods for collection literals that do not need to grow — they communicate intent clearly and prevent accidental mutation.

list.sort(comparator) sorts in place using a Comparator for custom ordering. Comparator.comparingInt() extracts an integer sort key — equivalent to Ruby's sort_by. Comparator.reverseOrder() reverses natural ordering. Comparators can be chained with .thenComparing() for multi-key sorting, analogous to sort_by { [_1.length, _1] } in Ruby.

Java's if/else if/else works identically to Ruby's if/elsif/else, with two syntactic differences: conditions must be enclosed in parentheses, and bodies must be enclosed in curly braces (or a single statement, though braces are always recommended to prevent subtle bugs). Java uses else if (two words) where Ruby uses elsif (one word, no space).

The switch expression (Java 14+) is a significant improvement over the old switch statement. The arrow -> syntax eliminates fall-through, allows multiple case labels per arm, and makes the whole construct an expression that returns a value — directly analogous to Ruby's case/when. Older Java code uses switch statements with break on every arm; the expression form is always preferable in modern Java.

Java's for loop is C-style: initializer, condition, and increment expression all appear in the header. Ruby rarely uses index-based loops — the idiomatic style is .times, .each, or .map. In Java, the C-style loop is common when an explicit index is needed; for iterating over a collection, use the enhanced for loop instead.

The enhanced for loop (for-each loop) iterates over any Iterable — arrays, lists, sets, map key/value sets, and so on. It is the closest Java equivalent to Ruby's .each. The colon : reads as "in": for (String fruit : fruits) means "for each fruit in fruits". The loop does not provide an index; use the C-style for loop or IntStream.range() when you need the index.

Java's while loop is syntactically identical to Ruby's except the condition requires parentheses and the body requires curly braces. Java also has a do/while loop (uncommon in practice) that guarantees the body executes at least once. Unlike Ruby, Java has no until loop or loop keyword — while (true) with a break is the standard idiom for an infinite loop.

In Java there are no standalone functions — every method must belong to a class. static methods belong to the class itself rather than to an instance, making them callable without creating an object (analogous to Ruby module methods). Unlike Ruby, Java methods require explicit return type declarations in the signature, and return is always written explicitly — there is no implicit return of the last expression.

Method overloading allows multiple methods with the same name but different parameter signatures. Java resolves the correct version at compile time based on argument types and count. Ruby achieves similar flexibility with optional and keyword arguments — Java's approach is more explicit and type-safe. Overloading is pervasive in Java's standard library: System.out.println(int), println(String), and println(double) are all separate method implementations.

Varargs (Type... name) allow a method to accept any number of arguments of a given type. Inside the method, the parameter behaves as an array. Java's int... numbers is the direct equivalent of Ruby's splat operator *numbers. A varargs parameter must be the last parameter in the signature, and a method may have at most one.

Method references (ClassName::methodName) are shorthand for a lambda that simply calls a single method. String::toUpperCase is equivalent to the lambda word -> word.toUpperCase(). They are the Java equivalent of Ruby's &:method_name shorthand (Symbol#to_proc). Method references can refer to instance methods on the argument, static methods, and constructors (ClassName::new).

Java lambdas are anonymous function objects implementing a functional interface. The type must be declared explicitly — Function<Integer,Integer> for a function taking and returning an Integer, BiFunction<A,B,R> for one with two inputs. The function is invoked with .apply(), not .call() as in Ruby. Ruby's lambdas are more flexible; Java's must conform to exactly one of the types in java.util.function.

The Stream API (Java 8+) provides functional-style operations on sequences. stream() converts the collection to a Stream, filter() keeps elements matching the predicate (equivalent to Ruby's select), and collect(Collectors.toList()) converts the result back to a list. Streams are lazy — intermediate operations do not execute until a terminal operation (collect, forEach, findFirst, etc.) is called.

map() on a stream transforms each element, producing a new stream with the same number of elements — exactly Ruby's Enumerable#map. The resulting stream's type changes to match the mapping function's return type. Use mapToInt(), mapToDouble(), or mapToLong() to get a primitive stream, which unlocks direct .sum(), .average(), and .max() operations without collecting first.

reduce() on a stream is equivalent to Ruby's Enumerable#reduce (also called inject). The two-argument form takes an identity value and a combining function; the single-argument form returns an Optional<T> because an empty stream has no meaningful value. For numeric sums, mapToInt().sum() is more readable and more efficient. The Optional return type forces the caller to acknowledge the empty-stream case.

Collectors.groupingBy() is the Java equivalent of Ruby's group_by — it partitions stream elements into a Map keyed by the classifier function. Collectors.joining() concatenates strings with a separator, analogous to Ruby's Array#join. Other useful collectors include Collectors.counting() (count per group) and Collectors.toMap() (arbitrary key/value extraction). Wrapping in new TreeMap<>() sorts the output by key.

Streams are designed for chaining — each intermediate operation returns a new Stream so multiple transformations compose in a single pipeline that executes only when the terminal operation is reached. Java's .sorted() corresponds to Ruby's .sort, .limit(n) to .first(n), and .filter() to .select(). The pipeline style reads top-to-bottom, mirroring Ruby's method chaining idiom.

Java and Ruby classes share the same structure: fields hold state, constructors initialize instances, and methods define behavior. The key differences are explicit type declarations on every field and parameter, and the constructor name matching the class name rather than Ruby's initialize. this in Java is equivalent to Ruby's self — it disambiguates between a parameter and a field when they share a name.

Java conventionally makes fields private and exposes them through getter and setter methods (getName(), setAge()) — the JavaBeans naming convention. This is the Java equivalent of Ruby's attr_reader and attr_accessor. Many frameworks (Spring, Hibernate, Jackson) rely on this convention for automatic configuration. Modern Java prefers records for immutable data, which generate accessors automatically without getters/setters.

Java uses extends for inheritance (Ruby uses <). super() in a constructor calls the parent constructor, exactly like Ruby's super. The @Override annotation is not required but is strongly recommended — it causes a compile error if the annotated method does not actually override anything, catching typos silently. Java supports single inheritance only; additional behavior is composed through interfaces.

Abstract classes in Java cannot be instantiated — they exist only to be subclassed. Abstract methods declare a contract that all concrete subclasses must fulfill, enforced at compile time. Ruby lacks abstract classes; the convention is to raise NotImplementedError at runtime, which is a weaker guarantee. In Java, forgetting to implement an abstract method is a compilation error. Abstract classes may contain concrete methods (with implementations) alongside abstract ones.

static fields and methods belong to the class itself, not to any instance — shared across all instances. This is the Java equivalent of Ruby's class variables (@@var) and class methods (def self.method). Static members are accessed via the class name (Counter.getCount()), not via an instance. The main method itself is static — it can be called by the JVM before any instance is created.

Records (Java 16+) are a concise syntax for immutable data classes. A record declaration automatically generates a constructor, accessor methods named after the components (x() and y(), not getX()), equals(), hashCode(), and toString(). Records are the Java equivalent of Ruby's Data.define() or a frozen Struct. All components are implicitly final — records are inherently immutable and thread-safe.

Custom methods can be added inside the record body and have full access to the record's components. Because components are final, methods that "modify" a record must return a new instance — the translate method above returns a new Point rather than mutating the existing one. This immutable-update pattern is the Java equivalent of Ruby's Data#with.

Java interfaces define contracts — method signatures (and optional default implementations) that implementing classes must provide. A class declares implements InterfaceName and must implement all abstract methods. Unlike Ruby modules, interfaces cannot hold instance state. Default methods (Java 8+) allow an interface to provide a method body — the closest Java equivalent to Ruby module methods that call abstract methods defined by the including class.

A Java class may implement multiple interfaces, separated by commas — this is how Java achieves the mixin-like composition that Ruby does with include. If two implemented interfaces have conflicting default methods with the same signature, the class must explicitly override the method to resolve the ambiguity. Java allows only single inheritance of classes (extends) but unlimited interface implementation (implements).

A functional interface has exactly one abstract method and can be satisfied by a lambda. Java's java.util.function package provides the standard set: Predicate<T> (boolean test via .test()), Function<T,R> (transform via .apply()), Consumer<T> (side effect, no return), Supplier<T> (provide value), BiFunction<T,U,R> (two inputs). Ruby's blocks, procs, and lambdas are first-class without this ceremony — Java's functional interfaces are the scaffolding that makes lambdas fit into the type system.

The instanceof pattern (Java 16+) tests the type and binds the cast result to a new variable in one step. Before Java 16, you had to write if (value instanceof String) { String text = (String) value; ... } — three steps instead of one. This is the Java equivalent of Ruby's case/when with class matching. The bound variable (text, count) is only in scope within the branch where the pattern matched.

Switch pattern matching (Java 21+) combines type testing and value extraction directly in a switch expression. The when keyword adds a guard condition, equivalent to Ruby's case/in with if. Patterns are tested top to bottom and the first match wins. Applied to sealed class hierarchies, the compiler can verify all cases are covered without a default clause — analogous to exhaustive matching in Rust or Kotlin.

Sealed classes (Java 17+) restrict which classes may extend or implement them — the permits clause names every allowed subtype. This enables exhaustive pattern matching: if Shape can only be Circle or Rectangle, the compiler knows the switch handles all cases and no default is needed. This is Java's approach to algebraic data types, a concept familiar from Rust, Kotlin, and Haskell. Ruby has no equivalent — duck typing makes such restrictions impossible to express in the type system.

Java's try/catch/finally is structurally identical to Ruby's begin/rescue/ensure. The finally block always runs regardless of whether an exception was thrown — it is Java's ensure. Multiple catch blocks handle different exception types; Java 7+ allows catching multiple types in one block with catch (IOException | SQLException error). Unlike Ruby, Java requires an explicit try block around the code that might throw.

Java has two exception categories: checked (subclasses of Exception that are not RuntimeException) and unchecked (subclasses of RuntimeException). Checked exceptions must either be caught or declared in the method signature with throws — failing to handle them is a compile error. This forces callers to acknowledge potential failures at API boundaries. Ruby has no equivalent — all exceptions are unchecked. The throws clause serves as compile-time-enforced documentation of what can go wrong.

Custom exceptions extend either Exception (checked) or RuntimeException (unchecked). Extending RuntimeException is common for application-level errors that callers are not always expected to catch. The constructor calls super(message) to set the message retrievable via getMessage(), directly paralleling Ruby's StandardError. By convention, exception class names end with Exception.

Try-with-resources (Java 7+) automatically closes any AutoCloseable resource at the end of the block, even if an exception is thrown. It is the Java equivalent of Ruby's block form (File.open(...) { |file| ... }) or an ensure block with explicit close(). Any class implementing AutoCloseable works: file streams, database connections, network sockets. Without try-with-resources, forgetting to close a resource is one of the most common Java bugs.

Generics let a class work with different types while preserving compile-time type safety. Box<T> is a blueprint where T is a type parameter filled in at use time. The key benefit over Ruby's duck typing: numberBox.content() is guaranteed at compile time to return an Integer, so numberBox.content() + 8 needs no cast and cannot fail at runtime with a type error. Ruby's equivalent works at runtime without type parameters because every object is always an object.

Generic methods declare their type parameter before the return type: <T> T methodName(...). The compiler infers T from the argument types at the call site — firstOrDefault(List.of(1, 2, 3), 0) infers T = Integer without any explicit annotation. Generic methods are the Java mechanism for writing reusable, type-safe utility functions, equivalent to Ruby's duck-typed methods but with compile-time guarantees instead of runtime ones.