JavaScript.CodeCompared.To/Java

There is also a compile step: javac turns source into bytecode before java runs it. Nothing executes until the whole file type-checks, which is the central trade this page is about.

Use %n rather than \n in a format string — it emits the platform line separator. The format string is checked at runtime, not compile time, so a mismatched specifier throws rather than failing to build.

This is the clearest place JavaScript simply wins: no dependency, no annotations, no object mapper. The Java compensation is that once a library does deserialize the JSON, you get a typed Employee the compiler understands, rather than an object whose shape is only a hope.

final is the counterpart of const — it prevents reassignment, not mutation. The commented line is a genuine compile error, which is the whole point: the class of bug that surfaces at runtime in JavaScript is refused at build time here.

Collections cannot hold primitives, which is why you see List<Integer> and never List<int>. Autoboxing hides the conversion but not its cost, and an unboxed null Integer throws NullPointerException at the moment it is used as an int.

The verbosity buys certainty: there is no list of falsy values to memorize and no argument about whether an empty array should be true. Note that String.isBlank() also treats whitespace-only strings as empty, which is usually what you meant.

The JavaScript column accepts "TYPO_SURVIVES" without complaint; the Java one cannot be passed anything that is not a Status. Enums also work in switch with exhaustiveness checking, and values() gives you the full set for iteration.

The bound variable — text, items — is in scope only where the check succeeded, so the old cast-after-check pattern is gone. List<?> uses a wildcard because generics are erased, and instanceof List<String> would not compile.

The 0.1 + 0.2 line is identical in both languages because Java's double is the same IEEE-754 type JavaScript uses for everything. The difference is that Java lets you avoid it by choosing an integer type.

Integer.MAX_VALUE + 1 is negative — a wrap, with no warning. The Math.addExact family throws ArithmeticException instead, and BigInteger is the unbounded option, matching JavaScript's BigInt.

Always construct from a String, never a double — new BigDecimal(0.1) captures the binary approximation you were trying to escape. Compare with compareTo rather than equals, since equals also compares scale, so 0.30 and 0.3 are unequal.

Literals are interned, so "hello" == "hello" happens to be true — which is worse than if it always failed, because it lets the bug survive testing. Use equals unconditionally, and compareTo where JavaScript would use <.

The += loop that is ordinary practice in JavaScript is a recognized performance mistake here, quadratic in the number of appends. For joining a known collection, String.join is clearer than either.

The indentation stripping is what JavaScript lacks, and it is why template literals in JS codebases are so often written flush against the left margin. Text blocks perform no interpolation, though — use formatted() for that.

The double backslash is the most common transcription error moving a regex from JavaScript to Java. Pattern.compile outside a loop is worth doing — unlike a JavaScript regex literal, the compilation is not cached for you.

Printing an array directly gives you [Ljava.lang.String;@1b6d3586 — arrays do not override toString, so Arrays.toString is required. The out-of-bounds throw is a real improvement: the error surfaces at the access rather than as an undefined traveling through your program.

List.of(...) builds an immutable list — calling add on it throws UnsupportedOperationException, which is why it is wrapped in new ArrayList<>(...) here. Note also size() is a method, unlike the length property on arrays.

You never get JavaScript's [1, 10, 100, 9] surprise, because the compiler knows the elements are Integer. Comparator.comparing composes with thenComparing and reversed(), which is more expressive than a hand-written comparison function.

Note Set.of(1, 2, 2, 3) would throw rather than deduplicate — the factories reject duplicate elements, which is why this builds the set from a List. Immutability here throws at runtime rather than being caught by the compiler, unlike final.

The last line prints first where JavaScript prints undefined. A record generates equals and hashCode from its components, making it a correct map key for free — this is one of the clearest wins Java has over JavaScript.

A plain HashMap has no defined iteration order — use LinkedHashMap when insertion order matters, as it does here, or TreeMap for sorted keys. JavaScript objects and Map both preserve insertion order, so this is a distinction you have not had to make before.

A TreeMap keeps keys sorted at all times rather than sorting on demand, and adds navigation methods — firstKey, headMap, ceilingKey — that have no JavaScript counterpart short of re-sorting an array.

Because it is an expression, the result can be assigned to a final variable in one statement — the JavaScript version needs a mutable let declared before the switch. Forgetting break is not a possible bug in this form.

Note there is no default branch and none is needed — permits tells the compiler the list is complete. The Rectangle(double width, double height) case is a record deconstruction pattern, binding the components directly, which is closer to JavaScript destructuring than anything else in Java.

Note that languages.get(index) is O(1) on an ArrayList but O(n) on a LinkedList — the interface hides a performance characteristic that the indexed loop then depends on. This is why the enhanced for loop is preferred where the index is not needed.

A ternary mixing incompatible branches — flag ? "text" : 42 — is a compile error in Java but perfectly legal in JavaScript, where the result is simply a union of whatever the branches produce.

Java has no default parameter values, so the one-argument overload delegating to the fuller one is the standard idiom. Overload resolution happens on the static type of the arguments, which occasionally surprises people expecting runtime dispatch.

Spreading an existing array means passing the array itself, since a varargs parameter is an array — there is no ... spread operator at the call site. Mixing varargs with overloading makes resolution genuinely hard to predict, so most codebases avoid the combination.

The duck-typed impostor in the JavaScript column has no Java equivalent — an object of an unrelated class cannot stand in, however matching its methods. this also always means the receiver here; it can never be lost by detaching a method.

Structural equality comes free, which JavaScript can only approximate with the order-sensitive JSON.stringify trick. Accessors are named after the component — name(), not getName() — and records are shallowly immutable, so there is no setter to write.

A subclass constructor must call super(...) first — there is no way to touch this before the parent is initialized. Java also has no prototype chain to inspect or modify: the hierarchy is fixed at compile time.

A static final field assigned in a static block is a constant computed once at class-load time. Note that a static method cannot reference this or any instance field, which the compiler enforces — JavaScript would let the mistake reach runtime.

The cost is ceremony; the benefit is that the compiler knows every implementor and refuses a type that does not qualify. A class may implement many interfaces but extend only one class, which is how Java approaches multiple inheritance.

The Person record satisfies name() automatically with its generated accessor, so the whole type is one line. Unlike a JavaScript mixin, nothing is copied at runtime and the compiler resolves conflicts between two interfaces offering the same default.

The <T> before the return type declares the type parameter, and it is inferred at each call site. Generics are erased at runtime — the bytecode does not know T — which is why you cannot write new T[] or test instanceof List<String>.

The lambda must be invoked through its interface method — doubler.apply(21), not doubler(21). A Java lambda also captures this from the enclosing instance and never rebinds it, so the arrow-versus-function distinction that matters so much in JavaScript has no counterpart.

A stream is single-use — reusing one throws IllegalStateException, where a JavaScript array can be iterated forever. The mapToInt step exists to escape boxing, a concern with no JavaScript analog.

The key type is Character and Integer here, not a string — JavaScript's Object.groupBy coerces every key to a string, so grouping by a number gives you "5". Use Map.groupBy there when that matters.

There are four forms — static, bound instance, unbound instance, and constructor (Employee::new). The unbound form used here, String::toUpperCase, treats the stream element as the receiver, which is exactly the case JavaScript cannot express without bind or a wrapper arrow.

There is no ?. operator for general use, so a deep access needs either nested checks or Optional. Modern JVMs produce helpful NPE messages naming the exact expression that was null, which makes the failure far easier to diagnose than a stray undefined.

Use Optional for return types, not for fields or parameters — that is the community convention, and it is not enforced. Calling get() without checking defeats the purpose and throws, so prefer orElse, orElseThrow, or ifPresent.

Objects.equals is the null-safe comparison — calling first.equals(second) throws when first is null, a mistake JavaScript's === makes impossible. requireNonNull at a method's entry converts a distant, confusing NPE into an immediate one that names the parameter.

Extending Exception makes it checked; extending RuntimeException makes it unchecked and JavaScript-like. Whether checked exceptions are worth the friction is Java's longest-running argument — but the compiler genuinely will not let you forget a documented failure.

Multi-catch alternatives may not be related by subclassing — NumberFormatException | IllegalArgumentException does not compile, because the first extends the second and the broader one already covers it. Clauses are otherwise tried top to bottom, so a more specific type must precede a broader one. Only Throwable subclasses can be thrown at all, unlike JavaScript where a bare string is legal.

Correct cleanup is the shortest thing to write here, which is the opposite of the JavaScript situation where forgetting finally silently leaks. A stage-3 using declaration is coming to JavaScript but is not yet dependable.

A blocking call like join() or Thread.sleep() stops only that thread; the equivalent in JavaScript would freeze the entire program. In exchange you inherit data races and must reason about shared mutable state, which JavaScript never forces on you.

Replacing AtomicInteger with a plain int here would usually print something under 2000, and would do so intermittently — the worst kind of bug. The absence of this whole problem is the strongest argument for JavaScript's single-threaded model.

allOf returns CompletableFuture<Void> and does not collect results, so each future must be read individually — Promise.all hands you the array directly. Note the throws Exception on main: get() is checked.

The blocking Thread.sleep inside a virtual thread parks it without holding an OS thread, so a million of these is practical. Note the synchronizedList — the shared collection still needs protection, because virtual threads are still genuinely concurrent.

ExecutorService became AutoCloseable in JDK 19, so try-with-resources shuts the pool down and waits — before that, forgetting shutdown() left the JVM running forever. Results are collected in submission order because the futures are read in order.