Full round replay — Arrays.sort

Pass: Objects that compare equal can still be distinguishable, so their input order carries information — that is what a second sort key relies on. Two equal ints are the same value, so no program can observe which came first, and the JDK is free to sort in place without the O(n) working array a stable merge needs.

Fail: Says primitives are faster, or treats stability as a performance property.

Pass: Sort by name, then by department. A stable department sort leaves the names alphabetical inside each department; an unstable one discards that work. It is how most group-then-order requirements are implemented.

Fail: Can define stability but cannot produce a case where it matters.

Pass: Wrap the comparator to count calls. A million already-sorted elements cost exactly n-1 comparisons, which only a run-detecting merge sort can do — that is the minimum needed just to verify the array is ordered. A quicksort partitions regardless and never learns the input was sorted.

Fail: Says you cannot, or only quotes the documentation.

Pass: It overflows. A large positive minus a large negative wraps and flips sign, so the comparator reports the wrong order. Nothing throws — the array comes back unsorted. Integer.compare or Comparator.comparingInt instead.

Fail: Says it is fine, or thinks it throws.

Pass: TimSort detected that the comparator is not a valid total order — usually subtraction overflow, or a compare returning 0 for 'close enough'. It is a check inside the merge step, so it needs at least 32 elements to fire at all, and beyond that it depends on the data.

Fail: Believes the exception reliably catches bad comparators.

Pass: No. The check is a diagnostic, not a validation — it cannot fire below 32 elements and above that it is data-dependent. A subtracting comparator mis-sorts silently. Silence is not evidence.

Fail: Takes the absence of the exception as proof.

Pass: It reverts to the pre-Java-7 merge sort, which tolerates a broken comparator by producing a wrongly ordered array instead of complaining. It removes the only signal that the ordering was ever wrong. Fix the comparator.

Fail: Treats it as a legitimate fix, or has no view.

Pass: Not since JDK 14. DualPivotQuicksort tracks recursion depth and falls back to heap sort past a limit. The same rewrite added run detection, so a nearly-sorted int[] is much cheaper than a random one. The attack is still worth knowing as a concept.

Fail: Confidently describes the quicksort-killer attack as current.

Pass: Not by sorting. A bounded min-heap of size ten is O(n log k) with O(k) memory — each element costs one comparison against the current smallest and is usually rejected. sorted().limit(10) is a full sort, because sorted() is a barrier and limit saves nothing. If the rows come from a database, ORDER BY with LIMIT and an index is better than all of it.

Fail: Sorts everything and takes the first ten.

Pass: Large arrays with cores to spare, in a batch job. Below about 8,192 elements it just calls the sequential sort, and it runs on the common ForkJoinPool, so in a service handling concurrent requests it adds contention rather than speed. It also needs more memory, not less.

Fail: Says it is always faster on a multicore machine.