Compare Comparable and Comparator, decode binary-search insertion points, and choose sets or maps using accurate Java SE 25 behavior.
Answer: Comparable<T> defines a type's natural ordering through compareTo(T). Comparator<T> defines an ordering in a separate object through compare(T,T). A type can offer a natural order while callers supply different comparators for specific uses.
For instance, a title value can sort naturally by title while an external comparator reverses that order. The selected comparison must satisfy its contract and remain stable during sorting.
Answer: java.util.Arrays provides static sort overloads for primitive and reference arrays, including range-based forms. Comparator overloads apply to reference arrays. Arrays is a class; java.util is the package containing it. Sorting changes the specified array or range in place.
Answer: Both can use the elements' natural ordering or a supplied comparator. Reference arrays use Arrays.sort, and lists use List.sort or Collections.sort. An array is itself an object, but the ordering operation compares its elements rather than sorting the array object as a single value.
A list must support the needed modification. An array has fixed length, although its elements can be rearranged. Sorting retains duplicates in both cases.
Answer: Arrays.sort and Collections.sort are static utility methods. List.sort is an instance method invoked on a list. They are different entry points to sorting; naming a method sort does not by itself make it static. Stream.sorted is another operation and returns a sorted stream rather than modifying its source.
Answer: The chosen ordering must be able to compare every relevant pair consistently. Natural-order sorting requires compatible Comparable elements; a comparator can handle types without a natural order. Null elements require an ordering that supports them, such as Comparator.nullsFirst.
A comparator must also obey sign consistency and transitivity. A sorting implementation may detect some broken comparators, but lack of an exception does not prove that the comparison rule is valid.
Answer: Each relevant pair can be compared by the selected ordering without an incompatible-type failure. Having different runtime classes is not automatically disqualifying: a comparator over a common type can define how to compare them. Conversely, merely implementing Comparable somewhere does not make arbitrary types compatible.
For example, Integer and Long natural ordering do not directly compare to each other. A deliberate Comparator<Number> can define a cross-type policy, but it must address numeric precision rather than silently treating every number as an exact double.
Answer: A nonnegative result is an index of a matching element. A negative result is -(insertionPoint) - 1; recover the insertion point with -result - 1. It is the position before the first element greater than the key under the selected ordering, or the end if no element is greater.
In the sorted array [2, 5, 9], searching for 7 returns -3, which decodes to insertion index 2. Searching for 5 returns 1. For duplicate matches, binarySearch does not promise the first or last matching position.
import java.util.Arrays;
import java.util.Comparator;
public class SearchInsertion {
public static void main(String[] args) {
int[] values = {2, 5, 9};
int result = Arrays.binarySearch(values, 7);
System.out.println(result);
System.out.println(-result - 1);
System.out.println(Arrays.binarySearch(values, 5));
Integer[] descending = {2, 9, 5};
Comparator<Integer> order = Comparator.reverseOrder();
Arrays.sort(descending, order);
System.out.println(Arrays.toString(descending));
System.out.println(Arrays.binarySearch(descending, 5, order));
}
}
Answer: Binary search requires input sorted according to the same ordering used by the search. If you sort with a reverse comparator, search with that comparator too. Searching unsorted data has undefined results under the API contract; it is not required to throw an exception.
A linear search such as list.contains does not need sorted input. For frequent insertion and sorted lookup, a TreeSet or TreeMap may be a more suitable structure than repeatedly sorting a list.
Answer: Choose a Set when the data model requires unique elements and membership operations. HashSet uses equality and hashing; LinkedHashSet adds defined encounter order. TreeSet uses comparison equality and supports sorted navigation, so its comparison rule should be consistent with equals.
Choose a List when duplicate occurrences or indexed positions matter. A Set does not store a count of each repeated value; use a map from value to count for that requirement.
Answer: No. They solve different problems: HashMap associates keys with values, while HashSet stores membership and is backed by a HashMap. With suitable hash distribution, their basic key or element operations have expected constant-time performance. Both depend on correct equality and hashing.
Compare equivalent operations such as map.containsKey and set.contains under a representative benchmark. Unique keys do not make HashMap immune to hash collisions, and no universal speed ranking follows from one storing values.
Java SE 25 references: Comparable, Comparator, Arrays, Collections, List, HashSet, HashMap.