TypeScript.CodeCompared.To/Java

None of this ceremony is optional, and all of it is load-bearing: public so the launcher can call it, static so it runs without an instance, void because the exit status comes from System.exit, and String[] args because that is the signature the launcher looks for. Getting one word wrong produces "main method not found" rather than a compile error.

The format string brings back something a template literal never had: width and precision control, so "%.2f" and "%,d" are one call rather than a toFixed and a locale helper. It also brings back the mismatch a template literal made impossible — %d against a String throws at runtime, not at compile time.

The rule is that the shortest leading run of whitespace across all lines (and the closing delimiter, if it is on its own line) is removed from each. It is the one place Java's string syntax is more comfortable than TypeScript's — a template literal in a nested block either breaks the indentation or silently includes it.

Reflection is the capability with no TypeScript counterpart at all, and it is why the Java ecosystem looks the way it does: dependency injection, object-relational mapping, and JSON binding are all built on asking a class about itself at runtime. The TypeScript equivalents have to be given a schema, because there is nothing to ask.

Fields, method parameters and return types all need their type spelled out — there is no inference for any of them, and no const-versus-let default to argue about because plain var is mutable. Note also that final, like const, forbids only rebinding: a final List can still be added to.

The middle line is false because the runtime caches boxed integers from -128 to 127 and allocates a fresh object above that — so the same code is correct for small numbers and wrong for large ones. This is the reason the rule is absolute: never compare boxed values with ==. Use the primitive types where you can, and equals everywhere else.

The last line is the whole difference. as is a promise the compiler accepts and nothing verifies, so a wrong one leaks a undefined that fails much later somewhere unrelated; a Java cast fails immediately, at the line that was wrong, with the actual class in the message. instanceof String text is a pattern: it tests and binds in one step, so the cast usually disappears entirely.

The L suffix matters: without it the literal is an int and will not compile because it does not fit. That pickiness is what buys the third line — a long is exact to 2⁶³, where every whole number above 2⁵³ in TypeScript is an approximation with nothing to warn you.

Both languages fail quietly past their limit, but they fail differently: an int becomes hugely negative while a number starts skipping odd values. The important practical difference is that Java's limit is 2 147 483 647 for the default integer type, which real data reaches — an id column, a millisecond count, a byte total.

Build a BigDecimal from a string, never from a double — new BigDecimal(0.1) faithfully preserves the error you were trying to escape. TypeScript has no standard equivalent; the options are a decimal library or integer arithmetic in the smallest unit.

The trap for a TypeScript developer is writing 'A' where a String is wanted, which does not compile, and the trap after that is letter + 1, which is 66 rather than "A1". Indexing a string gives a char too, so word.charAt(0) + word.charAt(1) is 165.

Both lines are true in TypeScript and only the second is true in Java — which means == on strings appears to work perfectly until a value arrives from a file, a network response, or a StringBuilder. Always equals, and "literal".equals(value) when value might be null.

The TypeScript column has to leave the string, work in an array, and come back, because there is nothing between "immutable string" and "array of characters". A builder is also an object you can hand to another method and keep appending to, which no TypeScript idiom offers — join works on a finished array and += works on one variable.

substring is stricter than slice: it rejects negative indices and throws StringIndexOutOfBoundsException past the end, where slice quietly clamps. Prefer strip over the older trim — trim only removes characters below U+0020 and misses most Unicode whitespace.

Plain compareTo compares UTF-16 code units, so every uppercase letter sorts before every lowercase one and "Apple" beats "apple" — the same trap as sorting with < in TypeScript. Locale-aware ordering is a java.text.Collator, which is where localeCompare's behavior actually lives.

An array also comes pre-filled with the element type's zero value — new int[3] holds three zeros, never undefined — so there are no holes and no sparse arrays. Because the length cannot change, almost all real code uses List instead, and arrays survive mainly for primitives and for varargs.

Declaring the variable as List rather than ArrayList is the convention, so the implementation can change without touching callers — LinkedList for cheap insertion at the ends, CopyOnWriteArrayList for concurrent reads. Note that List.of is immutable at runtime: calling add on it throws, where readonly is erased and cannot.

Sorting numbers needs no comparator at all here — list.sort(null) or Collections.sort uses each element's natural order, so the lexicographic surprise TypeScript's bare sort() springs on numbers cannot happen. sort mutates the list; stream().sorted(...) is the copying form, matching toSorted.

One kind of destructuring did arrive in Java 21, and it is limited to records: a record pattern can pull a record's components apart in a switch or an instanceof. Arrays and lists have nothing equivalent, and neither does object literal destructuring, because there are no object literals.

The awkward part coming from TypeScript is the return type: get hands back null for a missing key, and if the map holds Integer that null unboxes into a NullPointerException the moment you do arithmetic with it. getOrDefault exists precisely because nothing in the type system warns you, the way number | undefined does.

Note the choice of class: a HashMap iterates in an unspecified order that can change between runs, so LinkedHashMap is what you want whenever insertion order matters. TypeScript's Map gives that guarantee unconditionally, which is why nobody coming from it thinks to ask.

A Set in TypeScript compares members with ===, so a set of objects is really a set of identities: the second add stores a duplicate and the lookup with a fresh literal finds nothing. Working around it means keying by a serialized string, which is the pattern this row makes unnecessary — a record gets equals and hashCode generated for free.

There is no standard sorted collection in TypeScript, so keeping order means re-sorting the keys on every read — fine for a handful of entries, quadratic for a loop over many. TreeMap also answers questions an array cannot without a scan: ceilingKey, floorKey and subMap are all logarithmic.

The whole class of bug where if (count) silently rejects a legitimate 0, or if (text) rejects the empty string, cannot be written. What replaces it is a different mistake: if (value != null) when the value is a Boolean object, which compiles and then throws on unboxing if it is null.

No break, no let-then-assign, and no way to forget a branch when the subject is an enum or a sealed type — the compiler requires every case to be covered and rejects the switch otherwise. The old colon form still exists and still falls through, so a mixed codebase has both.

The counted loop over a List is fine for an ArrayList and quietly quadratic for a LinkedList, because get(index) walks from the head — a cost TypeScript arrays never have. There is no for...in equivalent and nothing to confuse it with.

The library answers are Objects.requireNonNullElse(supplied, "fallback") for a single value and Optional for a chain, both covered in the Null section. Neither short-circuits a dotted path the way a?.b?.c does, so a three-deep access is either three tests or three Optional.map calls.

This is why the standard library is a directory of noun-shaped holders — Math, Objects, Collections, Arrays, Files — where TypeScript would export loose functions from a module. A static import can strip the prefix at the call site, but the method still has to live somewhere.

Three separate bodies, no union parameter, and no runtime tag-checking — the choice is made at compile time and costs nothing. The limits are the same as TypeScript's: you cannot overload on return type alone, and because the choice uses static types, an argument declared as Object selects the Object overload no matter what it actually holds.

There are no named arguments either, so a method with five optional settings would need thirty-two overloads. That is why the builder pattern exists: an object you configure with chained calls and finish with build(), doing the job that an options object with optional properties does in one line of TypeScript.

Calling one means remembering which single method its interface declares — apply, get, accept, test — and the family stops at two arguments, so a three-argument lambda needs an interface you write yourself. The compensation is Person::name, a method reference, which is shorter than any arrow function for the very common case of "just call this method".

The upside is that two types cannot be confused just because they happen to look alike, so Meters and Feet are genuinely different types with no branding trick required. The downside is real work: when a library type fits your interface but never declared it, you cannot pass it, and something has to bridge the gap.

A method reference such as words::size is the cheapest adapter available, and it works only because Sized has exactly one abstract method. For an interface with several, the adapter is a class — which is what the adapter and wrapper patterns in every Java codebase are for, and why they barely exist in TypeScript.

This is how the standard library evolves without breaking anyone: Iterable.forEach and Collection.stream were added as default methods, so every existing implementer gained them for free. The TypeScript equivalent is a free function taking the interface — which works, but does not arrive through the type.

For this particular comparator a lambda would do, and Comparator.comparingInt(String::length) is shorter still. The anonymous class earns its keep when the interface has several methods — an event listener with onStart and onStop — where TypeScript would pass an object literal of functions.

Every call site in the TypeScript column has to remember the comparison function, and a call that forgets sorts lexicographically without complaint. Declaring it once in the type is the trade nominal typing keeps offering: more ceremony at the declaration, and no ceremony at all afterwards.

A class with no constructor gets an implicit no-argument one, and writing any constructor removes it — the source of "constructor BankAccount in class BankAccount cannot be applied to given types" the first time you add one. Records, in a later section, are the answer when a class is only carrying data.

Package-private has no TypeScript counterpart at all: module scope is per-file, so a helper shared by three files must be exported and is then visible to everything. It is also the default here, which surprises people — leaving off the keyword does not mean public.

TypeScript has no hook for any of this: === cannot be overridden, there is no hash protocol, and toString is consulted only by string conversion. Comparing by content is a function you write and remember to call — which is why the JSON.stringify comparison above, fragile about key order and useless for cyclic data, keeps getting used anyway.

A subclass constructor must call super(...) first if the parent has no no-argument constructor — the parameter properties that make the TypeScript version a single line have no counterpart. final has no TypeScript equivalent either: nothing there can forbid a subclass from replacing a method.

Accessors are name(), not getName() — the JavaBeans convention does not apply to records. Every component is final, so a record is shallowly immutable, and the generated toString prints Person[name=Ada, born=1815], which is why records are pleasant in logs where a plain class prints an address.

The last two lines of the TypeScript column are the point: a factory function only guards the door it is standing at, and the type itself allows any object of the right shape. When a type is a name rather than a shape, the constructor is the only door, so an invalid instance cannot be built at all.

Notice what the Java column gets for free that the TypeScript one has to arrange: one method handles both shapes, because the pattern tests the type as well as binding the parts. TypeScript destructuring never tests anything — it assumes the shape the annotation claims and reads undefined when the claim is wrong.

This is the one place records are clearly worse than an object literal: the constructor call lists components you did not touch, and adding a component to Article means finding every such call. The usual mitigation is a hand-written withTitle method on the record, or a builder — and a with expression has been proposed for the language but has not shipped.

Each constant is a singleton, so == is the right comparison for enums — the one place reference identity is idiomatic. They also come with values(), name(), ordinal(), and the specialized EnumMap and EnumSet, which are backed by an array indexed by ordinal and are far faster than a hash map.

The never trick in the TypeScript column is doing by hand what the Java compiler does by construction, and it has a hole the Java version does not: the argument is a plain string at runtime, so a value from JSON that is not one of the three reaches the default branch. An enum constant cannot be forged.

The cost is three declarations where TypeScript has one type alias, and the members must be named up front in the permits clause. What you get back is a discriminant that cannot be spoofed, an area that a caller cannot pass a wrong-shaped object to, and exhaustiveness enforced by the language rather than by a never idiom you have to remember.

The default branch exists because the compiler cannot rule anything out — Object is every type, so the check moves from build time to run time, which is exactly the direction nobody wants. When the set of alternatives is fixed and yours, a sealed interface restores the guarantee; when it is String or Integer, types you do not own, there is no way to say so.

The <> in new Box<>(21) is the diamond: the type argument is inferred from context, so it is rarely written out. A type parameter cannot be a primitive, so Box<int> is illegal and Box<Integer> is what you write — every value in a generic container is boxed.

Both columns print the same two answers; the only visible difference is the comparator the TypeScript version has to be handed at every call. It has to be handed one because there is no way to say "a type that implements Comparable" when conformance is never declared — a bound can only describe a shape, and "compares to itself" is not a shape. The flip side is that a Java bound cannot say "anything with a numeric length", so when no shared interface exists the method cannot be written generically at all.

Java arrays are covariant too, and that is old and acknowledged as a mistake — but the runtime still checks every store and throws ArrayStoreException, so the corruption is caught at the moment it happens. TypeScript makes the same unsound choice and has no runtime to catch it, so the array in the anchor column now holds a number and nothing anywhere knows.

You cannot write list instanceof List<String> — the type argument is gone — but list instanceof List works, because List itself is a real runtime type. TypeScript has neither half: an interface leaves nothing behind at all, so even the unparameterized check has nothing to test against.

Rename name in the TypeScript column and all three derived types stop compiling until they are updated; rename it in the Java column and the two extra records go quietly stale. This is the one capability TypeScript has that Java has no answer to at any level — not generics, not annotations, and not reflection, which reads types but cannot create them.

This is the single biggest safety regression coming from TypeScript: the compiler that has been refusing your possibly-null dereferences for years stops, and the failure moves to run time. Java 14 at least made the message specific — it names the expression that was null — but nothing prevents the call. Annotations such as @Nullable are convention plus a linter, not part of the language.

The advice, which surprises people, is to use it only for return values — not for fields, not for parameters, and not in collections, where it adds an allocation and a second way to be empty. So string | undefined covers ground Optional deliberately does not, and a nullable field remains a plain nullable field.

The plain alternative — contractor.manager() == null ? "no manager" : contractor.manager().email() — evaluates the accessor twice, which is fine for a record and wrong for anything with a side effect. Neither form short-circuits the way ?. does, so a four-deep path is four chained map calls.

The ! suffix is erased, so the program carries the wrong value onward and fails at the dereference, wherever that happens to be — the message names the property, not the argument. Putting requireNonNull at the top of a constructor or a public method is the standard way to make a null fail at the boundary it crossed.

The split is between RuntimeException and its subclasses, which are unchecked and behave the way every TypeScript error does, and everything else, which is checked. Checked exceptions are the most argued-about feature in the language, and the reason lambdas are awkward around I/O: none of the standard functional interfaces declare throws, so a checked exception inside a map has to be wrapped.

Because the clause is typed, the exception variable is typed too — no unknown, no instanceof ladder, and no cast to read getMessage(). It also means an exception you did not name simply propagates, where a single untyped catch swallows everything unless you remember to rethrow.

The finally version works and is what TypeScript still needs, but it puts the cleanup a long way from the acquisition and gets forgotten when a second resource is added. JavaScript is acquiring the same idea as using declarations with Symbol.dispose; until that is everywhere, finally is the tool.

Setting this.name has no counterpart and needs none — the class name is already in the stack trace, because the class is really there. The other thing you get free is a cause chain: passing a cause to super keeps the original exception and the printed trace shows both, where an Error needs the cause option and code of your own to walk it.

This is why a Java catch can be typed at all, and why the error binding in TypeScript is unknown: any value at all can arrive there, including undefined, so every handler starts by working out what it caught. The rare cost is that you cannot throw a lightweight value for control flow — an exception always allocates a stack trace unless you suppress it.

The extra ceremony buys laziness: nothing happens until the terminal operation asks, and the elements flow through the whole chain one at a time, so no intermediate list is ever built. A five-stage array chain in TypeScript allocates five arrays; the stream allocates none.

Composition is what Object.groupBy lacks: counting per group means grouping first and then mapping the result, where groupingBy(first, counting()) does it in one pass. Wrapping in a TreeMap above is deliberate — groupingBy returns a HashMap, whose iteration order is unspecified.

A generator is the closest TypeScript equivalent and is genuinely more flexible — it can receive values back through next(value) — but it comes with no operators, so limit, map and filter over one are written by hand or imported. Both are one-shot: consuming a stream or a generator twice fails.

The orElse is there because average returns an OptionalDouble — an empty stream has no average, and the type says so. IntStream.range is also the idiomatic counted loop replacement, since there is no Array.from({ length: n }, ...) trick to reach for.

start() launches the thread and returns immediately; join() blocks the caller until it finishes. Blocking is the ordinary way to wait here — there is no event loop to starve — which is why the whole vocabulary of not blocking that TypeScript is built around simply does not come up.

The fixes are AtomicInteger, which makes the increment a single indivisible operation, or a synchronized block, which lets only one thread into the critical section at a time. Neither has a TypeScript counterpart, because two of your statements never overlap: counter += 1 is effectively atomic by construction. This example cannot be run in the browser: the execution environment has limited thread support.

Note int captured = value: a lambda can only capture a variable that is effectively final, so the loop variable has to be copied — a restriction let in a for loop removed for JavaScript years ago. Forgetting shutdown() leaves non-daemon threads alive and the program never exits, which has no equivalent failure mode in Node.

There is no async/await syntax, so the chain stays in callback form and a conditional in the middle of it is genuinely awkward — the readability that await bought JavaScript has no equivalent. What Java has instead is that join() can simply block: waiting costs a parked thread rather than restructuring the function.

The point is that Thread.sleep here is an ordinary blocking call in ordinary sequential code, and it scales like await — no coloring of functions, no async spreading up the call stack, and a stack trace that shows the whole path. This example cannot be run in the browser: the execution environment has no support for virtual threads. It runs on any JDK 21 or later.

An import brings a type into scope, never a function or a value, which is why import static java.lang.Math.max; is a separate form. Nothing is exported explicitly either: public on the type is what makes it visible outside its package, and the default is visible only within it.

The dependency earns its place, because it does something JSON.parse cannot: it binds the document to a record and fails on the spot when a field is missing or the wrong type, where JSON.parse returns any and every downstream type is a guess. That is reflection again — the library reads the record's components at runtime and matches them to keys.

An annotation never rewrites the thing it is attached to, which is the opposite of a decorator: @Deprecated and @Entity only record a fact, and something else — the compiler, an annotation processor, or a framework reading them reflectively — decides what it means. That is why annotations have been stable for twenty years while JavaScript decorators went through several incompatible designs.