پرسش‌وپاسخ سریع: زبان جاوا، Collections و JVMRapid-Fire Q&A: Java Language, Collections & JVM

With the banknotes picture: for objects, == compares references (identity) — "do these two slips carry the same address?". For primitives it compares the raw value (a primitive isn't an address, it's the number itself).

equals() is the semantic/value comparison that each class defines for itself. The crucial catch: the default Object.equals has no magic — it is literally just ==! Until you override it, "equal" means "the very same physical object."

Objects.equals(a, b) is the null-safe version. Its logic is simple: if both are null, true; if exactly one is null, false; otherwise it calls a.equals(b). Why is that good? Because if a is itself null and you write a.equals(b), you get a NullPointerException; Objects.equals defuses that trap for you.

This contract is the beating heart of how HashMap and HashSet work, so burn it in: if a.equals(b), then a.hashCode() == b.hashCode() — mandatory. It's one-directional and required.

The reverse is not required: two unequal objects may share a hashCode. That's called a "collision" and it's perfectly legal (later, in HashMap, you'll see why it's unavoidable).

Break this rule and hash-based collections silently lose your objects: you put, then get, and receive null — with no error at all. These bugs cost hours. On top of that, equals must have four properties: reflexive (a.equals(a) is always true), symmetric (if a.equals(b) then b.equals(a)), transitive (if a=b and b=c then a=c), and consistent (same answer until the object changes).

Exactly the library picture above. Two objects you've defined as "equal" can land in two different buckets (shelves), because their default hashCode (based on memory address) differs.

The precise mechanism: HashMap.get and HashSet.contains first locate the bucket by hashCode, then search inside that bucket with equals. So if the hashCode is wrong, they never even reach the right bucket and your correct equals never gets called. Classic bug: a value object (an object whose identity is defined by its value, like a point or a money amount) used as a map key that suddenly "disappears."

String a = "java";
String b = "java";
String c = new String("java");
System.out.println(a == b);          // true  – both point to the pooled literal
System.out.println(a == c);          // false – new String() forces a heap object
System.out.println(a == c.intern()); // true  – intern() returns the pooled ref

With the central-board picture: a and b both point to the same board slot, so a == b is true. But new String("java") is like someone insisting "no, I want my own separate sheet of paper" — it allocates a fresh heap object whose value is equal but whose address differs, so a == c is false. The intern() method says "take this word to the central board and give me the board's address," so c.intern() hands back the pooled reference and a == c.intern() is true. Summary: compile-time constant literals are deduplicated, new String() always allocates fresh, and intern() canonicalizes to the pool.

Integer a = 127, b = 127;
Integer c = 128, d = 128;
System.out.println(a == b); // true  – cached (-128..127)
System.out.println(c == d); // false – autoboxing creates new Integer objects

Here we have "autoboxing": when you drop a raw int into an Integer (the object version of int), Java behind the scenes calls Integer.valueOf(...). And this method has a small optimization: it pre-builds the commonly-used range -128..127 and keeps it in a cache. So 127 is the same cached object every time ← a == b is true. But 128 is outside the cached range, so a fresh object is built each time, and == (which compares references) gives false. The upper bound of this cache is tunable via the -XX:AutoBoxCacheMax flag. Practical lesson: to compare boxed values, never trust ==; always use .equals or intValue().

Overloading = same name, different parameter list. Resolved at compile time based on the static type (the type you declared in code) — the compiler decides right then which version gets called.

Overriding = the exact same signature in a subclass. Resolved at runtime based on the dynamic type (the object's actual type at that moment) — this is called "virtual dispatch": the decision is deferred to runtime. Golden interview line: overloading is polymorphism's impostor — because it isn't dynamic. Real polymorphism is overriding.

void f(Object o) {}
void f(String s) {}
f(null); // calls f(String) – most specific applicable overload wins

null can be converted to either type, so which wins? The compiler's rule: pick the most specific applicable type. Since String is a subtype of Object (more specific), f(String) wins. But if you add another equally-specific overload, like f(Integer), the compiler can no longer decide which of String or Integer is more specific ← ambiguity compile error. To disambiguate, spell out the type yourself with a cast: f((Object) null) explicitly calls the Object version.

Since Java 8 the line between them blurred, so be precise. Interfaces can now have default (bodied) methods, static, and private methods — but they have no instance state; they may only hold public static final constants. A class can implement many interfaces but extend only one abstract class (Java has no multiple class inheritance).

The practical rule for choosing: if you want to provide shared state and a partial base implementation, use an abstract class. If you want to define a capability or contract ("this thing can fly"), use an interface. And the diamond note: interfaces make the diamond problem solvable only when you override the conflicting default yourself.

interface A { default String hi() { return "A"; } }
interface B { default String hi() { return "B"; } }
class C implements A, B {
    public String hi() { return A.super.hi(); } // MUST override, or won't compile
}

"Diamond" means a class inherits along two paths that both provide a same-named method with a default body — the compiler is stuck on which hi() to inherit. Java hands the ambiguity back to you: until you override hi() yourself, the code won't compile. Inside the override you can use the special syntax Interface.super.method() — here A.super.hi() — to explicitly say "I want A's version." That's the only way to point at a specific default among several interfaces.

"Immutable" means that after construction its contents never change. Java guarantees this with three locks: the backing character array is private final (not visible outside the class and never reassigned), it's never handed out, and the String class itself is final so no sneaky subclass can change its behavior.

Why does it matter? Four benefits: (1) It's a safe HashMap key, because its hashCode is computed once and cached and never shifts. (2) It's safe for interning/pooling (the central board). (3) It's inherently thread-safe — something that never changes has no concurrent race. (4) It's safe in security contexts: if you validated a file path, nobody can secretly change it after the check. The cost? Every "modification" actually allocates a brand-new object.

One word, four places, four meanings:

• On a local/field: assigned exactly once (then locked).
• On a method: cannot be overridden in a subclass.
• On a class: cannot be subclassed (like String itself).

And the most important interview trap: final does not mean immutable. Example:

final List<String> l = new ArrayList<>();

Here you can't reassign l to a different list (the reference is locked), but you're perfectly allowed to call l.add("x") — the list's contents are still mutable. final locks the reference, not the object's contents.

Generics are a compile-time-only tool. The compiler erases type parameters down to their bound: an unbounded T becomes Object, and <T extends Number> becomes Number. Then, wherever needed, it injects casts itself to keep the code safe. Result: at runtime List<String> and List<Integer> are the exact same class — neither carries its type "label."

The costs (memorize these; they're asked directly): you can't do new T[], there's no T.class, instanceof List<String> is illegal, you can't overload on signatures that collapse to the same thing after erasure, and you keep getting "unchecked cast" warnings. All these limitations have one root: at runtime, the type information is simply no longer there.

List<String> ls = new ArrayList<>();
List<Integer> li = new ArrayList<>();
System.out.println(ls.getClass() == li.getClass()); // true – same runtime class
void m(List<String> a) {}
void m(List<Integer> b) {} // COMPILE ERROR: both erase to m(List)

The first line prints true and gives away the whole story: since both lists are just ArrayList at runtime, getClass() is identical. Now why does the second line fail? Because after erasure both methods collapse to the same signature m(List), and the compiler won't accept two methods with the same signature. Overloading on generic type arguments is impossible, for exactly this reason.

Yes, and now with the conveyor picture it makes sense. When you only read T out of a structure (the structure produces T for you), use ? extends T. When you only write T into a structure (the structure consumes T), use ? super T.

The canonical example everyone loves to ask:

Collections.copy(List<? super T> dest, List<? extends T> src)

The destination (dest) is a consumer (we write into it) so ? super T; the source (src) is a producer (we read from it) so ? extends T. And the two logical limitations that follow: you cannot add anything but null to a ? extends list (you don't know its exact subtype), and you cannot safely read a specific type from a ? super list (you only know it's "some supertype of T").

All three look similar but behave worlds apart:

• List<Object>: accepts any element, but — key point — a List<String> is not a List<Object>. This is called "invariance": generics do not pass their elements' subtyping up to themselves.
• List<?>: the unbounded wildcard. You read its elements only as Object and you can't add anything but null (the conveyor limitation).
• raw List: disables generic checking entirely and reintroduces ClassCastException risk into your code. It exists only for compatibility with pre-generics legacy code; avoid it in new code.

Here two opposing philosophies collide. Arrays are covariant and reified: "reified" means they remember their component type at runtime, and if you try to store the wrong type in them, they throw an ArrayStoreException at runtime. But generics are invariant and erased — at runtime they carry no type information at all.

If new T[] were allowed, the array wouldn't know its real type anymore and that runtime guard (ArrayStoreException) would break. So Java forbids it outright. Two workarounds: either (T[]) new Object[n] with a suppressed warning (@SuppressWarnings), or, more professionally, Array.newInstance(...), which takes a Class<T> token so it truly knows the type at runtime.

It has an array of buckets (lockers). The bucket index is computed by (n-1) & hash, where n is the number of buckets. But there's a subtle trick: hash = h ^ (h >>> 16). What does that do? It XORs the high bits of the hash code into the low bits, so that when only the low bits are used for the index, the variety of the high bits participates too and collisions drop.

When several objects land in one bucket, they first form a linked list (a simple chain). But if a single bucket exceeds 8 entries and simultaneously the whole table size is ≥ 64, that chain converts into a red-black tree (called "treeify") so the worst-case lookup improves from O(n) to O(log n). Default capacity is 16, load factor 0.75; as soon as the entry count crosses capacity × load factor, a resize happens: the table doubles and everything is re-hashed.

It's a space-vs-time trade-off. If you set the load factor low (say 0.5), the table is always sparse and collisions are rare — but lots of memory is wasted and resizes happen sooner. If you set it high (say 0.9), the table gets dense, memory is saved, but chains get long and lookups slow down. 0.75 is the empirical sweet spot giving good average O(1) lookup at acceptable memory cost.

fail-fast (like ArrayList and HashMap): they keep an internal counter called modCount that increments on every structural modification. If this counter changes during iteration, the iterator throws a ConcurrentModificationException (CME for short). Note: this is "best-effort," not a hard guarantee — it doesn't always catch it, but usually does.

fail-safe (like CopyOnWriteArrayList and ConcurrentHashMap): they either iterate over a snapshot or tolerate concurrent change; they never throw, but may show you slightly stale data. A point many get wrong: even in a single-threaded program, if you call list.remove() inside a for-each loop, you get that same CME. The right way: Iterator.remove() or removeIf.

for (String s : list) {
    if (s.isBlank()) list.remove(s); // throws ConcurrentModificationException
}
// Fix:
list.removeIf(String::isBlank);      // or Iterator.remove()

The reason is exactly the previous box: for-each uses an iterator behind the scenes, and list.remove(s) directly on the list changes modCount without the iterator knowing. On the next loop turn, the iterator sees the inconsistency and throws CME. removeIf does the job from inside the structure itself, safely.

The honest answer: almost never — and that's itself a good interview answer. ArrayList is a contiguous array in memory: O(1) random access (jump straight to slot i), CPU-cache-friendly (data sits together), and amortized cheap append.

LinkedList has O(1) insert/remove — but only if you already hold the target node. In practice get(i) and index-based removal are O(n), because you must walk node by node from the head. Worse: each node is a separate object with memory overhead, and its scattering trashes the CPU cache. The only real justification for LinkedList is as a Deque, and even there ArrayDeque usually wins.

• Hashtable: an old relic. It has a synchronized lock on every method (a coarse global lock that locks the whole map), and it rejects null as both key and value. Set it aside.
• HashMap: unsynchronized (no lock), fast, and allows one null key. Great for single-threaded use.
• ConcurrentHashMap: thread-safety with high concurrency. Java 8 uses CAS (an atomic lock-free "compare-and-swap" operation) on empty bins and synchronizes only the head node of a bucket (fine-grained locking, not global). It rejects null as key or value, and its iterators are weakly consistent: they don't throw but may not see last-moment changes.

Because of a fatal ambiguity in a concurrent setting. Suppose map.get(k) returns null. What does that mean? Two cases are possible: "the key doesn't exist at all" or "the key exists but its value is deliberately null." In an ordinary map you could tell them apart with a second containsKey. But concurrently, between your get and your containsKey, another thread could change the map — so that second check isn't reliable (it's racy). By forbidding null, the ambiguity is eliminated entirely: a null return definitively means "absent," and get alone is authoritative.

Three completely different ordering behaviors:

• HashMap: no ordering guarantee at all. Iteration order can differ each time.
• LinkedHashMap: preserves insertion order. And a lovely trick: if you build it with accessOrder=true, its order becomes most-recently-accessed; now if you also override removeEldestEntry, you have a ready-made LRU cache (least-recently-used gets evicted).
• TreeMap: keeps elements sorted, by natural order or a Comparator. Its operations are O(log n) (it's a red-black tree) and it supports NavigableMap range queries: floorKey (largest key ≤ x), ceilingEntry (smallest entry ≥ x), subMap (a range), and so on.

Map<List<Integer>, String> m = new HashMap<>();
List<Integer> key = new ArrayList<>(List.of(1, 2));
m.put(key, "x");
key.add(3);                    // hashCode changes after insertion
System.out.println(m.get(key)); // null – it's in the old bucket, now unreachable

Remember why they made String immutable so it'd be a good key? Here you see the opposite. Your key is a mutable List. At put time, Java picks its bucket using the hashCode at that moment (based on [1, 2]). Then you call key.add(3) and now the hashCode, based on [1, 2, 3], has changed. At get time, Java searches with the new hashCode and goes to a bucket where the key simply isn't — so null. The key still sits in the old bucket but is no longer findable. Lesson: never mutate a key after insertion; prefer immutable keys.

Comparable = the class's own natural ordering; you implement compareTo on the object itself ("how does this thing inherently sort"). Comparator = an external, swappable ordering placed in a separate object ("sort by name once, by age another time").

And the classic trap: (a, b) -> a - b. This overflows for large ints — e.g. if a is Integer.MIN_VALUE, then a - 1 wraps around and flips sign, so the comparator breaks its contract and sorting corrupts. The right way: Integer.compare(a, b), which has no such trap. Bonus point: a comparator inconsistent with equals also corrupts TreeSet/TreeMap semantics (they judge equality by the comparator, not by equals).

Two different algorithms, depending on what you're sorting:

• Objects: TimSort is used; a stable, adaptive merge sort with O(n log n) complexity, that on nearly-sorted data speeds up to O(n). "Stable" means the order of equal elements is preserved.
• Primitives: a dual-pivot Quicksort is used, which is unstable — but stability is meaningless on primitives (two 5s are indistinguishable), so it doesn't matter.

And a practical warning: if your comparator is non-transitive (i.e. a<b and b<c but not a<c), TimSort may, during its invariant checks, throw the famous IllegalArgumentException: Comparison method violates its general contract.

checked (a class that extends Exception but not RuntimeException): the compiler forces you to either catch it or declare it in the method signature. Designed for recoverable conditions — like "file not found," where the program can do something about it.

unchecked (RuntimeException and Error): no obligation. For programming bugs (like NullPointerException) and unrecoverable states (like OutOfMemoryError).

And the modern criticism worth stating in an interview: checked exceptions don't compose with lambdas and streams (you can't easily throw a checked exception inside a map(...)) and they encourage "swallowing" errors (empty catch). That's why many teams wrap them in unchecked exceptions at system boundaries.

try-with-resources is a construct that automatically closes resources (like a file or connection). Two precise points interviewers love: resources close in reverse declaration order (last opened, first closed — like taking off clothes), and this closing happens before any catch or finally.

Now the subtle scenario: if the body throws AND close() also throws while closing, which one propagates? The body's exception wins and propagates; the close exception is suppressed and attached to the primary one — you can retrieve it via getSuppressed(). This is exactly the opposite of a hand-rolled finally { close(); }, in which if close throws, the original body exception is lost. That's why try-with-resources is always better.

static int f() {
    try { return 1; }
    finally { return 2; } // finally's return SWALLOWS the try's return AND any exception
}
// f() returns 2. A return/throw in finally overrides everything. Never do this.

finally always runs, even after a return is queued in try. When finally itself has a return 2, that value replaces the buffered value from try (which was 1). Worse: if try had thrown an exception, the return inside finally swallows that exception too and makes it vanish. That's why it's a dangerous bug.

static int g() {
    int x = 1;
    try { return x; }        // return value (1) is evaluated & buffered here
    finally { x = 99; }      // mutates local, but the buffered return is unaffected
}
// g() returns 1, not 99 — the return expression was already computed.

Grasp this subtlety well: when you reach return x, Java reads the value of x (i.e. 1) right then and sets it aside (buffers it). Then finally runs and changes x to 99 — but that no longer affects the buffered value, because that number was already copied. So the output is 1. The difference from Q30: there, finally itself had a return (so it replaced the return value); here, finally only tweaks a local variable.

Two broad categories:

Shared across the whole JVM: (1) heap — all objects live here and GC manages it. (2) Metaspace — class metadata (their structure, methods, etc.); an important version note: since Java 8 this area lives in native memory (outside the heap) and replaced the old PermGen area.

Per-thread: (3) JVM stack — frames with local variables and operands. (4) PC register — tells which instruction the thread is currently executing. (5) native method stack.

Two extra points worth knowing: the string pool lives in the heap (moved from PermGen to the heap in Java 7). The -Xmx flag sets the heap ceiling, and -XX:MaxMetaspaceSize bounds Metaspace.

Remember the address-slip-and-house picture? Here's where it pays off. The object body and all its instance fields live on the heap (the real house, in the warehouse). A local reference variable lives on the stack and merely points into the heap (the address slip, on your desk). Primitives declared as local variables live on the stack (the number itself, on your desk); but primitives that are fields of an object live inside that heap object.

The senior-flavored point: escape analysis is a JVM optimization that detects an object doesn't "escape" the method scope (never leaks out anywhere), and may then stack-allocate it or even break it into plain scalars (scalar replacement). This is an optional optimization, not a language guarantee.

A class goes through these phases: Loading → Linking (comprising Verify, Prepare, Resolve) → Initialization.

• Prepare: sets static fields to their default values (e.g. an int to 0).
• Initialization: runs static initializers and the actual assignment of static fields — and this happens lazily, on the first active use of the class.

parent-delegation: before a classloader loads a class itself, it first asks its parent. The chain: Bootstrap → Platform → Application. Result: Java's core classes (like java.lang.String) are always loaded from the highest level, and nobody can slip in a forged replacement.

The golden point: the special method <clinit> (which is the static initialization code) is run once and thread-safely by the JVM itself. This is precisely why the "initialization-on-demand holder" idiom (holding the instance in a static inner class) is a correct way to build a lazy, safe singleton — with no manual locking.

class A {
    static int x = 10;
    static { x = 20; }
    static int y = x + 5; // initializers run top-to-bottom: x is 20 here
}
// A.y == 25. Static blocks and field initializers execute in textual order.

The simple rule: static { ... } blocks and static field initializers run in textual order, top to bottom. So step by step: first x becomes 10, then the static block bumps it to 20, and when we reach y = x + 5, x is 20, so y becomes 25. Reorder the lines and the answer changes.

It gives two guarantees: (1) visibility — the notice board: writes are immediately flushed to main memory and reads come straight from there, so no thread sees a stale copy. (2) ordering — it establishes a happens-before edge and prevents reordering of instructions across the volatile access.

But — and this is the most important part of the answer — it does not give atomicity for compound actions. For instance, count++ on a volatile int is still a lost-update race, because count++ is really three operations (read, add, write) and two threads can interleave. For read-modify-write operations you must use AtomicInteger or a lock.

The Java Memory Model (JMM) gives a lovely guarantee: if an object is properly constructed — meaning the this reference doesn't leak out from inside the constructor — then any thread that sees the object's reference sees its final fields correctly initialized, without any synchronization. This guarantee is exactly what underpins safe immutable objects and, in particular, the safety of String itself (whose fields are final).

The key observation — the "weak generational hypothesis" — is that most objects die young. So we split the heap into two areas: Young (which itself contains Eden and two Survivor spaces) and Old.

The mechanism: new objects are born in Eden. A Minor GC copies the survivors between the two Survivor spaces and bumps their "age" by one. When an object's age crosses a threshold (the tenuring threshold), it's promoted to Old. Old is collected less often, with a Major/Full GC. Why is collecting Young cheap? Because it uses a copying algorithm that only touches the live objects — and by that same hypothesis, live objects in Young are very few.

A full map of collectors:

• G1 — the default since Java 9. Region-based (it splits the heap into small regions), targets a soft pause goal, and is compacting.
• Parallel — focused on throughput; fully stop-the-world.
• Serial — single-threaded, for small heaps and containers.
• ZGC and Shenandoah — concurrent low-latency collectors with sub-millisecond pauses.
• Generational ZGC (JEP 439, Java 21) — added young/old generations to ZGC; it cut memory use by about 75% and boosted throughput about 4× over the old non-generational ZGC.

The choice rule: take G1 by default; for latency-critical large heaps, ZGC or Shenandoah.

GC roots are the "your hands" of the kite picture: the starting points the collector treats as definitely alive. They include: references and local variables on the stacks of active threads, static fields, JNI references (from native code), and held monitors (acquired locks).

The general rule: an object is garbage if and only if it is unreachable from any GC root. And a subtlety that trips many up: two dead objects that only reference each other (a cyclic reference) are still collected — because the criterion is reachability from a root, not reference counting. If Java merely counted references, that dead cycle would never be freed.

Four degrees of "stickiness" to memory, from firm to loose:

• Strong: the ordinary, everyday reference. As long as it's reachable, it's never collected.
• Soft: collected only under memory pressure. Great for memory-sensitive caches — "keep it while there's room, drop it when things get tight."
• Weak: collected at the next GC, if only weakly reachable. It's the basis of WeakHashMap and canonicalizing maps.
• Phantom: enqueued after finalization for deterministic post-mortem cleanup; it's the modern, safe replacement for the finalize() method, which itself is deprecated for removal.

Yes, definitely. A static collection that you keep add-ing to and never remove from holds strong references forever — and since static is a GC root, none of those objects are ever freed. Classic culprits: caches without an eviction policy, listeners that get registered but never unregistered, and ThreadLocals not cleared on pooled threads (because that thread stays alive and carries its ThreadLocal with it). These are "logic leaks": from GC's viewpoint those objects are fully live and reachable, so it won't free them — the problem is in your logic, not in GC.

No. "stop-the-world" (STW for short) is the moment when all application threads pause at a safepoint (a safe point where state is stable) so GC can do its sensitive work. Even ZGC and Shenandoah — the ones called "low-latency" — have brief STW pauses (for root scanning and mark start/end), but they keep them sub-millisecond and do the heavy part (mark and relocation) concurrently with the running application. The golden interview line: "pauseless" is a marketing claim; the real, correct claim is "sub-millisecond pauses, decoupled from heap size."

Virtual threads are lightweight threads that the JVM itself schedules onto a small pool of carrier (platform) threads — the picture's real waiters. Here's the magic: instead of locking an OS thread, blocking I/O unmounts the virtual thread (detaches it from the carrier). Result: you can run millions of virtual threads in the simple "one thread per request" style without exhausting OS resources.

But the main catch: pinning. Before Java 24, if a virtual thread blocked inside a synchronized block or a native call, it stayed pinned to its carrier and couldn't unmount — meaning that real waiter got stuck and scaling was throttled. The fix: either use ReentrantLock instead of synchronized, or upgrade — JEP 491 (Java 24) removed synchronized-induced pinning at the runtime level.

Because it violates the entire virtual-thread philosophy. You do not pool virtual threads — you create one per task, with Executors.newVirtualThreadPerTaskExecutor(). Remember these are cheap and meant to be short-lived; pooling them is like setting up a laundry system for disposable paper tissues — it's pointless. Pooling is for the carrier threads, which the JVM manages and you don't touch. If you want to limit concurrency (say, at most 100 simultaneous calls to a service), use a Semaphore, not a bounded thread pool.

HashMap was never built for concurrent use, and the result isn't merely "wrong data" — it can be catastrophic. Concurrent puts right in the middle of a resize can corrupt the internal table. In Java 7, this could form a cycle in a bucket chain, and then a simple get would spin into an infinite loop that pegged the CPU at 100% and took down the whole service. Java 8's resize is less catastrophic (it no longer forms that infinite loop) but it still corrupts state and loses entries. There's no "partial safety" — for any shared mutable map, use ConcurrentHashMap.

System.out.println(0.1 + 0.2 == 0.3); // false – binary floating-point can't represent 0.1 exactly
System.out.println(0.1 + 0.2);        // 0.30000000000000004

Why? double stores numbers in base two (binary), and just as 1/3 in base ten becomes an endless 0.3333..., the number 0.1 in base two is an endless repeating fraction that must be truncated. These tiny truncation errors accumulate and 0.1 + 0.2 doesn't come out exactly 0.3 but 0.30000000000000004. The vital practical lesson: never use double for money; use BigDecimal — and construct it from a string (new BigDecimal("0.1")), not from a double, or you've imported the very same error from the start.

Long l = 0L;
System.out.println(l.equals(0)); // false! 0 autoboxes to Integer; Long.equals(Integer) is false

Here 0 (with no L suffix) is an int that boxes to Integer, not Long. And the first thing Long.equals(...) does is check the runtime type: since the argument is an Integer and not a Long, it immediately returns false — even though the values look equal. equals never converts between different numeric types. The right way: either l.longValue() == 0 (value comparison) or l.equals(0L) (with the right suffix so the argument is a Long).

System.out.println(Integer.MAX_VALUE + 1); // -2147483648 – silent int overflow wraps around

int has only 32 bits and its largest value is Integer.MAX_VALUE (which is 2147483647). Add one to it, and like a car's odometer flipping from 999999 to 000000, it wraps around to the most negative value (-2147483648) — and gives no error at all, silently. To make overflow fail fast and loudly instead of producing corrupt data, use Math.addExact(...) (which throws on overflow), or just use long.

String s = null;
switch (s) { ... } // NullPointerException – switch on a null reference throws before matching

A classic switch over a String or enum, before it reaches any case, must first extract the value (e.g. take its hashCode), and on null it throws a NullPointerException right there. The fix: either explicitly guard null beforehand (if (s == null) ...), or use the Java 21 pattern-matching switch, which has a real case null label so you can handle null like an ordinary case.