Java.CodeCompared.To/TypeScript

Every piece of ceremony Java requires — the class, the public static void main signature, the String[] args parameter — has no TypeScript counterpart. There is still a compile step, but it produces JavaScript rather than bytecode, and it is the JavaScript that runs.

The expression inside ${...} is type-checked, and its result is converted to text with the same rules as string concatenation. What you lose is width and precision control: there is no %.2f, so formatting a number means calling toFixed or toLocaleString on it first.

A Java text block strips the common indentation of its lines so the literal can sit at the indentation of the surrounding code. A template literal does not, which is why multi-line text in TypeScript is usually written against the left margin even inside a deeply nested block.

const forbids rebinding, exactly as final does — it says nothing about the value itself. A const array can still be pushed to and a const object can still have its properties reassigned, just as a final List reference can still be added to.

Writing these annotations out is legal but unusual: TypeScript infers all four from the initializers, and the house style is to annotate only where inference would be wrong or unhelpful. The types themselves are compile-time only — the emitted JavaScript is four bare const declarations.

The type "GET" is a literal type: a type whose only value is that string. It is what makes "GET" | "POST" a usable stand-in for an enum, and it is why passing a let-bound string where such a union is expected fails — the compiler already widened it to string.

A Java cast is verified by the virtual machine, so a wrong one throws a ClassCastException at the point of the mistake. TypeScript has no runtime check to fall back on, so unknown forces the test into your code — and any lets you skip both the test and the error, which is why it is the thing to keep out of a codebase.

The literal 9007199254740993 has no exact double representation, so it is rounded as it is read and prints back one less. Nothing warns you: there is no compile error, no overflow, and no long to move to. This is the single most surprising thing about carrying identifiers from a Java database into TypeScript.

The remainder operator agrees with Java in taking the sign of the dividend, so -7 % 2 is -1 in both. It is only the quotient that differs — and because the result is still a valid number, an accidental 3.5 travels a long way before anything notices.

A long that overflows wraps to a negative number; a number that runs past 2⁵³ starts skipping values instead. Neither is checked, but they fail differently. A bigint and a number cannot be mixed in one expression — 1n + 1 is a TypeError — which is the language forcing the conversion to be deliberate.

Because toFixed hands back a string, chaining more arithmetic onto it silently concatenates instead of adding. The Math namespace otherwise lines up closely with java.lang.Math, with ** available as an operator where Java has only Math.pow.

Repeated += in a loop also works and is heavily optimized by every engine, so the array-and-join form is chosen for readability rather than speed. What is genuinely absent is a builder object you can pass around and append to from several places.

slice is more forgiving than substring: it accepts negative indices to count from the end, and an out-of-range index clamps rather than throwing. That means a slicing bug shows up as a short string rather than a StringIndexOutOfBoundsException.

Both languages measure length in UTF-16 code units, so an emoji counts as two in each. The difference is that word.charAt(0) + 1 is arithmetic in Java and concatenation in TypeScript — the char-is-a-number trap simply does not exist.

Strings are primitives, so === is a value comparison and there is no equals to call. Objects are the opposite: === on two objects is reference identity and there is no equals for them either, so structural comparison has to be written by hand.

The type is written number[] or, equivalently, Array<number>. Because there is no boxing, an array of numbers holds numbers rather than Integer objects — the int[] versus List<Integer> performance decision has nothing to decide.

The comparator is a plain function returning a negative number, zero, or a positive number — the same contract as Comparator.compare, without the interface. Note also that sort mutates the array in place and returns it; toSorted is the copying version.

Java 21 brought record patterns, which destructure a record's components — but nothing destructures an array or a list. Spread is a shallow copy, so [...values] duplicates the array while leaving any objects inside it shared.

List.of gives you both guarantees at once: the compiler sees an immutable interface and the object throws if you get past it. TypeScript splits them, and the compile-time half is erased — a readonly array handed to plain JavaScript is an ordinary, fully mutable array.

The inferred type is { name: string; born: number }, so person.born is a number with no cast and a misspelled property is a compile error. The Java stand-in, a Map<String, Object>, gives up both — every read needs a cast and every key is unchecked.

get returns number | undefined, so the missing case is part of the type and the compiler makes you deal with it — which is what getOrDefault exists to paper over. Keys are compared with ===, so there is no equals/hashCode to implement, and equally no way to key a map by value.

Membership is ===, so two objects with identical contents are two separate members — a set of records that HashSet would collapse stays fully populated here. Spreading a set back into an array with [...tags] is the standard way to get at array methods.

These three helpers return arrays rather than the live views keySet and values give you, so they are snapshots. The catch is that Record<string, number> promises a number for every string key, so reading an absent one type-checks and hands back undefined.

There is a second loop spelled for...in, and it is almost never what you want: it walks an object's property names, so over an array it yields "0", "1" — strings, not numbers, and inherited ones too. Reach for for...of unless you specifically want an object's keys.

The convenience is also the hazard: if (count) is wrong whenever 0 is a legitimate value, and if (text) is wrong whenever the empty string is. When you mean "was this supplied", write the comparison out — count !== undefined — rather than leaning on truthiness.

Nothing checks that a switch over numbers covers every case, so the default is doing real work. Exhaustiveness checking does exist in TypeScript, but it arrives with discriminated unions rather than with switch itself — see the Unions section.

The return type is optional — TypeScript infers number here — but writing it is the usual habit, because it pins the function's contract instead of letting a change to the body quietly change the signature.

Arity is part of the type rather than part of the interface's name, so a three-argument function needs no TriFunction that the standard library forgot to include. Calling it is ordinary call syntax — there is no apply, accept or get to look up.

The default is an expression evaluated at call time, so it can refer to earlier parameters — function slice(text: string, end = text.length) is legal. Rest parameters arrive as a real array rather than as Java's array-that-might-also-have-been-passed-directly.

The two declarations are what callers see; the third is the implementation and is not callable directly. Nothing checks that the body actually handles every declared signature, and there is no overloading on return type alone — the same limit Java has, for the opposite reason.

This is why builders are rare in TypeScript: the object literal already gives you named, order-independent, optional arguments, and the compiler still checks that url was supplied and that no unknown property was passed. What it does not give you is a partially-built value you can pass around before it is complete.

There is no implements clause to forget and no adapter class to write when a type you do not own happens to fit an interface you do. The cost is the mirror image: two unrelated types with the same shape are interchangeable, so Meters and Feet defined as { value: number } are the same type.

The rule exists because a property nobody asked for, written inline, is nearly always a typo or a misremembered option name — the one case where structural typing would happily swallow a mistake. Assigning through a variable opts out of the check, which is also the usual way people work around it.

For plain object shapes the two are interchangeable, and teams pick one by convention. The functional difference is that an interface declared twice in the same scope merges its members, which is how ambient type definitions add to types they do not own — and is also a reason to prefer type when you want the name closed.

Java can only express the second half of "absent or null" — a field is always there and may hold null. The distinction matters as soon as data is serialized, because a missing JSON key and a null JSON value are different documents, and TypeScript can describe both.

Java has to choose: a class with fixed members, or a Map with none. An index signature is the hybrid — interface Response { status: number; [header: string]: string | number } declares one known property and leaves the rest open, with both halves checked.

Java gets this free — a wrapper type is a distinct type because of its name, and it costs an allocation. The branded version costs nothing at runtime, since the brand is erased and the value stays a plain string; what it costs instead is the as cast in makeUserId, which is the one unchecked hole the whole scheme depends on.

Choose # when the privacy has to hold against JavaScript callers and against anything reflective, and private when you only want the compiler to enforce a convention. A private field is plainly visible as counter["count"] at runtime; a # field is a syntax error outside the class body.

What a record gives you that this does not is equals and hashCode. There is no value equality anywhere in the language: two identically-built objects are never ===, they hash to nothing, and a Set or Map keyed by them treats them as distinct. Comparing by content means writing the comparison, and the JSON.stringify trick above is the crude version of it.

Because the call is invisible, a plain field can later become an accessor without touching any caller — the reason "always write a getter" never became a rule here. The flip side is that an innocent-looking assignment may run arbitrary code.

this.constructor.name is as close as you get to getClass().getSimpleName(), and it is a plain string with no class object behind it — there is no Class, no getDeclaredFields, and no reflection of any kind. A minifier will happily rename the class and change that string.

A Java method reference captures the receiver permanently, so greeter::greet can be passed anywhere. The three fixes here are bind, an arrow function that closes over the object, or declaring the member as an arrow-function field — and forgetting all three is the classic bug when a method is used as an event handler.

Java can express this only by inventing a hierarchy: an interface, a permits clause, and a record per case, all of which must be written before the union can exist. A TypeScript union is ad hoc — number | string can be written at the point of use, and number and string are untouched by it.

Because the value is just a string, it serializes and deserializes with no mapping layer — and it also arrives from the network entirely unchecked, so a validator at the boundary is doing work the type system cannot. TypeScript does have an enum keyword, but it emits a runtime object and behaves unlike everything around it, which is why literal unions are preferred.

Inside case "ok" the compiler knows result has a value and no message, so reading the wrong one is a compile error — the same guarantee case Ok(int value) gives. The discriminant is an ordinary property, which means it survives JSON.stringify and comes back intact.

A sealed interface gives Java this for free: a switch with no default must cover every permitted type, and adding a new one breaks the build. TypeScript needs the idiom written out, but the effect is the same — add a third member to the union and the never assignment stops compiling, naming the case you forgot.

Nothing checks that the body of a guard is honest — the compiler simply believes the signature, and a guard that returns true for the wrong values silently poisons everything downstream. That unverified promise is the price of erasure, and it is why validation libraries that generate both the checker and the type from one schema are so widely used.

Loose equality is worth avoiding everywhere else, but == null is the idiomatic exception: it is true for exactly null and undefined and nothing else. Most code avoids producing null at all and treats undefined as the single absence, which is the closest you can get to Java's one-hole model.

This is the one place TypeScript is meaningfully stricter than Java. Every Java reference is implicitly nullable and nothing forces a check, so a NullPointerException is always reachable; here the possibility has to be written into the signature, and once it is, the compiler will not let you ignore it.

Note that ?? is not ||: the older operator falls back on any falsy value, so count || 10 quietly replaces a legitimate 0. Use ?? whenever the fallback is meant for absence rather than for emptiness.

Java's implicit unboxing is the same kind of promise, and the difference is what happens when it is wrong: the JVM throws at the point of the mistake, while TypeScript produces NaN or undefined and carries it onward until something much later fails for a reason that no longer points at the cause.

Inference works the same way and fails in the same place — an empty array carries no evidence of its element type, so the call is written with an explicit <number> just as the Java call needs List.<Integer>of().

Strings and arrays both satisfy { length: number } without either of them implementing anything, which is why one function handles both calls. The Java column cannot be written to accept both: its bound has to name a supertype, and there is no interface that String and List both implement — so the list case is all it gets.

Neither language can write new T(), so both reach for a factory function passed in by the caller. What Java still has is getClass(), instanceof against a real class, and a Class<T> token you can hand around; TypeScript has typeof, Array.isArray, and instanceof against classes only — nothing that can see an interface or a type alias.

The soundness Java buys with invariance and wildcards is simply not bought here — this is a documented, deliberate unsoundness, traded for not having to write ? extends on every reading parameter. The closest thing to a producer-only declaration is readonly Animal[], which at least removes push from the type.

Because the type parameter is erased, a Box<string> and a Box<number> are the same object at runtime in both languages — but only Java can still ask the box what class it is. Note also that new Box(...) infers T, so the diamond has nothing left to elide.

Java has no way to compute a type from another type, so every projection of User is a separate record kept in step by hand — and adding a field to User silently leaves them behind. Rename name in the TypeScript version and all three derived types stop compiling until they are updated.

Note typeof defaults in type position: it lifts a value into the type world, so the settings object is declared once and its type is derived rather than duplicated. The Java version has to widen everything to Object and cast on the way out, and a mistyped key is a runtime null instead of a compile error.

This is the one corner of TypeScript with no Java counterpart at any level — not generics, not annotations, not reflection. Nullable<User> is written once and applies to every type you ever pass it, where the Java column must hand-write a parallel record for each shape and keep it in sync forever.

A Java enum also gives you the type and values() from one declaration, and gives you more besides — constructors, fields, methods, and a real identity. What it cannot be is a plain string on the wire, which is why the as const pattern wins wherever the values cross a network or a database boundary.

The price of the shorter spelling is that these are eager: each stage allocates a complete intermediate array, so a five-stage chain over a million elements builds five arrays where a Java stream builds none. For large data the answer is a generator, not a longer chain.

There is no downstream collector to compose, so counting or summing per group means a second pass over the grouped object rather than a Collectors.counting() argument. Keys are always strings, so grouping by a number gives you "1" rather than 1.

flat() descends one level by default and takes a depth argument — flat(Infinity) for all of them. Reaching for toSorted rather than sort is worth making a habit, because sort reorders the array you were handed, which is rarely what a caller expects.

The Java column has to name every component it is not changing, which is exactly the code that goes stale when a component is added. Spread is a shallow copy in both directions: renamed.tags is the same array object as user.tags, just as a record's component reference is shared.

A generator is iterable, so it works with for...of, spread, and destructuring, and it can be consumed only once — the same one-shot rule a Stream has. What it lacks is the operator vocabulary: there is no built-in limit or lazy map for generators, so those are written by hand or taken from a library.

Selecting on the exception type — what catch (IllegalStateException error) does for you — becomes an instanceof test inside the one clause, followed by a rethrow of anything you did not mean to handle. Forgetting that rethrow is how a catch quietly swallows unrelated failures.

A TypeScript signature tells you what a function returns when it succeeds and nothing whatsoever about how it fails, so the only way to know is to read the body — or the documentation, or the incident. That gap is the reason result-shaped return types (the next-but-one row) keep being reinvented.

Setting this.name is worth the extra line: it is what appears in a stack trace and in a logged error, and without it every subclass prints as Error. This is also why error hierarchies are built from classes rather than from interfaces or unions — an interface would leave nothing for instanceof to test.

The shapes are the same and so is the guarantee — reading result.value without testing result.ok does not compile — but the TypeScript version needs no interface, no permits clause and no record per case. Note also that Number("x") yields NaN rather than throwing, which is why the check is Number.isInteger and not a try.

await is written at the top level of a file here, which is legal because a module body is itself asynchronous — there is no main to make async and no join() to block on. Blocking, in fact, is not available at all: there is no equivalent of Future.get() that stops and waits.

The tuple type is preserved, so awaiting [compute(3), someText()] gives a [number, string] rather than an array of a union. Note what "at once" means here: the two calls make progress by interleaving on one thread, so this overlaps waiting, never computation.

Replace the AtomicInteger with a plain int in the Java column and the answer stops being 100000; the TypeScript column has no such version to get wrong. The price is that nothing gets faster on more cores — real parallelism needs Web Workers or a worker thread, which communicate by copying messages rather than by sharing memory. This example cannot be run in the browser: the execution environment has limited thread support. Run it anywhere else and it prints 100000.

The delay helper above is written out in nearly every codebase, because the standard library does not ship one. The upside of having no blocking sleep is that a waiting task costs nothing — there is no thread parked on it, which is the same benefit Java only recently got from virtual threads.

Anything not exported is private to its file, which is the real unit of encapsulation — there is nothing like package-private visibility across several files. The .js in the import path is not a typo: the specifier names the file that will exist after compilation, which trips up nearly everyone once.

The misspelling above compiles because any permits everything, which is exactly why every network and storage boundary wants a validator that checks the document and returns a properly typed value. Java has the opposite problem: no JSON at all in the standard library, so a dependency is mandatory — but that dependency does the checking.

structuredClone handles cycles, Map, Set, Date and typed arrays, and refuses functions and class prototypes — so a cloned object keeps its data and loses its methods. That last part is the one to remember: cloning a class instance gives you a plain object that no longer answers instanceof.