Comparable vs Comparator.

Comparable is the object’s built-in default sort, while Comparator is the outside rule you can swap in. Interviewers love this question because it checks whether you understand both sorting and how TreeSet/TreeMap decide uniqueness.

Question: Comparable vs Comparator.

Answer: Comparable is implemented by the class itself through compareTo() and gives that type one natural order. Comparator is a separate object with compare() that lets you define many different orderings for the same class. Use Comparable when there is one obvious default order; use Comparator when you need flexible, reusable, or temporary sorting rules.

Interview-Ready Answer: I’d say Comparable defines the natural order inside the class itself using compareTo(), so a type has one default way to be sorted. Comparator is external and defines custom ordering with compare(), so I can sort the same objects by age, salary, name, or anything else without changing the class. A useful detail is that sorted collections like TreeSet and TreeMap also use that ordering to decide when two objects count as the same key.

What each one means

Comparable is for a class that knows how it should be ordered by default. The method is compareTo മറ്റെരേഖ? No need

Comparator is an external comparison rule. It is a functional interface, meaning it has one abstract method, so you can use a lambda in Java 8+.

How Java uses them under the hood

1. A sorting algorithm asks two elements which one should come first.
2. If the type implements Comparable, Java calls compareTo() on the objects themselves.
3. If you pass a Comparator, Java calls compare() on that comparator instead.
4. For TreeSet and TreeMap, every insert, lookup, and removal walks a tree and compares nodes on the way down.
5. If the comparison returns 0, the structure treats the two values as equal for ordering purposes.
6. That is why ordering can affect not only sort order, but also whether a value is kept or dropped in a sorted set or map.

Comparable vs Comparator

When and why to use each one

• Use Comparable when the type has one obvious business ordering, like String alphabetically or Integer numerically.
• Use Comparator when users can ask for different views, such as by name, by date, by salary, or by priority.
• Prefer Comparator when you do not own the class, because you can still sort it without editing the source.
• Prefer Comparable for a default order that most code will want.

Performance and edge cases

Sorting a list is usually O(n log n); the comparison itself should be cheap because it is called many times. For sorted maps and sets, insert/search/delete are typically O(log n). In Java object sorting, List.sort() and Collections.sort() use a stable TimSort implementation, which can use up to O(n) extra space in some cases.

The big gotcha: if two different objects return 0 from compareTo() or compare(), a TreeSet or TreeMap may treat them as duplicates even if equals() says they are different. Also, if you use mutable fields such as name or status in your ordering and then change them after insertion into a sorted collection, the structure can become logically broken.

Real-World Story: Imagine a checkout service that shows urgent orders in a support dashboard. The team gives Order a natural order by priority, then by created time, because that is the default view most operators want. Later, analytics wants a different view by customer name, so the team adds a Comparator instead of changing the class again.

What goes wrong when someone misunderstands the difference? A developer makes compareTo() use only priority, ignoring the unique order id. In a TreeSet-backed queue, two different orders with the same priority are treated as the same item, so one disappears from the dashboard. The symptom is subtle: counts in the UI are lower than the database, logs show fewer inserts than expected, and support agents notice missing urgent orders even though the API returned success.

This is exactly why interviewers care: ordering is not just about pretty sorting on screen. In Java, the ordering rule can affect deduplication, lookup speed, and even whether a record survives insertion into a sorted collection.

Follow-up & Tricky Questions:

• What is natural ordering? It is the default order defined by the class itself, usually via Comparable.compareTo(). For String, that is lexicographic order; for numbers, it is numeric order.
• Can a class implement Comparable and still use Comparator? Yes. The class can provide one default order, and callers can still pass a different Comparator whenever they need another view.
• What happens if compareTo() is inconsistent with equals()? Sorted collections may behave strangely: two objects can be considered the same for ordering but not for equality. That can cause surprising drops in TreeSet or key replacement in TreeMap.
• Why is Comparator often preferred in modern code? It is more flexible and composable. Since Java 8 you can build it with lambdas, comparing, thenComparing, reversed, and null-handling helpers.
• Does Collections.sort() require Comparable? Only if you do not pass a comparator. If you pass a Comparator, the list elements do not need to implement Comparable.
• Can compareTo() or compare() return any negative or positive number? Yes; only the sign matters. Do not assume it must be -1, 0, or 1.
• Can a sorted set store objects that are not Comparable? Yes, but only if you give the set a Comparator up front. Without one, the failure appears at runtime when a comparison is needed.
• Is compareTo(this, other) allowed to use subtraction like a - b? It is risky because integer overflow can flip the sign. Use Integer.compare, Long.compare, or Double.compare instead.
• Tricky: if compareTo() returns 0, are the objects equal? Not necessarily. It only means they are equal in ordering; equals() may still return false, which is why sorted collections need careful design.
• Tricky: does TreeSet use equals() to detect duplicates? No, it uses ordering. If the comparator says two values are the same position, the second one is treated as a duplicate.
• Tricky: will the first insert into TreeSet<Object> fail without a comparator? Usually not, because no comparison is needed for the very first element. The error often appears on the second insert, when Java finally needs to compare values.

Common Mistakes:

• Mixing up the roles. Correction: Comparable lives in the class; Comparator lives outside the class.
• Using subtraction in compareTo(). Correction: use Integer.compare or similar helpers to avoid overflow.
• Forgetting the effect on TreeSet/TreeMap. Correction: compare result 0 means “same key” for sorted collections.
• Making the order depend on mutable fields. Correction: prefer stable fields like id, created time, or immutable business attributes.

Memory Hook: Think: Comparable = the object knows its own rank; Comparator = a referee carrying a different rulebook.

Cheat Sheet:

• Comparable → compareTo() → one natural order.
• Comparator → compare() → many custom orders.
• Comparable is inside the class; Comparator is passed in.
• Sorted collections use ordering for both sorting and uniqueness.
• Java 8+ makes Comparator easy with lambdas and chaining.

Practice Tasks:

• Implement Comparable for a Student class by GPA, then by name.
• Write a Comparator that sorts students by descending score and handles null names safely.
• Create a TreeSet and observe how changing the comparison fields changes which items are kept.