< prev index next >
src/java.base/share/classes/java/util/Comparator.java
Print this page
@@ -40,24 +40,24 @@
* over the sort order. Comparators can also be used to control the order of
* certain data structures (such as {@link SortedSet sorted sets} or {@link
* SortedMap sorted maps}), or to provide an ordering for collections of
* objects that don't have a {@link Comparable natural ordering}.<p>
*
- * The ordering imposed by a comparator <tt>c</tt> on a set of elements
- * <tt>S</tt> is said to be <i>consistent with equals</i> if and only if
- * <tt>c.compare(e1, e2)==0</tt> has the same boolean value as
- * <tt>e1.equals(e2)</tt> for every <tt>e1</tt> and <tt>e2</tt> in
- * <tt>S</tt>.<p>
+ * The ordering imposed by a comparator {@code c} on a set of elements
+ * {@code S} is said to be <i>consistent with equals</i> if and only if
+ * {@code c.compare(e1, e2)==0} has the same boolean value as
+ * {@code e1.equals(e2)} for every {@code e1} and {@code e2} in
+ * {@code S}.<p>
*
* Caution should be exercised when using a comparator capable of imposing an
* ordering inconsistent with equals to order a sorted set (or sorted map).
- * Suppose a sorted set (or sorted map) with an explicit comparator <tt>c</tt>
- * is used with elements (or keys) drawn from a set <tt>S</tt>. If the
- * ordering imposed by <tt>c</tt> on <tt>S</tt> is inconsistent with equals,
+ * Suppose a sorted set (or sorted map) with an explicit comparator {@code c}
+ * is used with elements (or keys) drawn from a set {@code S}. If the
+ * ordering imposed by {@code c} on {@code S} is inconsistent with equals,
* the sorted set (or sorted map) will behave "strangely." In particular the
* sorted set (or sorted map) will violate the general contract for set (or
- * map), which is defined in terms of <tt>equals</tt>.<p>
+ * map), which is defined in terms of {@code equals}.<p>
*
* For example, suppose one adds two elements {@code a} and {@code b} such that
* {@code (a.equals(b) && c.compare(a, b) != 0)}
* to an empty {@code TreeSet} with comparator {@code c}.
* The second {@code add} operation will return
@@ -65,27 +65,27 @@
* {@code b} are not equivalent from the tree set's perspective, even though
* this is contrary to the specification of the
* {@link Set#add Set.add} method.<p>
*
* Note: It is generally a good idea for comparators to also implement
- * <tt>java.io.Serializable</tt>, as they may be used as ordering methods in
+ * {@code java.io.Serializable}, as they may be used as ordering methods in
* serializable data structures (like {@link TreeSet}, {@link TreeMap}). In
* order for the data structure to serialize successfully, the comparator (if
- * provided) must implement <tt>Serializable</tt>.<p>
+ * provided) must implement {@code Serializable}.<p>
*
* For the mathematically inclined, the <i>relation</i> that defines the
- * <i>imposed ordering</i> that a given comparator <tt>c</tt> imposes on a
- * given set of objects <tt>S</tt> is:<pre>
+ * <i>imposed ordering</i> that a given comparator {@code c} imposes on a
+ * given set of objects {@code S} is:<pre>
* {(x, y) such that c.compare(x, y) <= 0}.
* </pre> The <i>quotient</i> for this total order is:<pre>
* {(x, y) such that c.compare(x, y) == 0}.
* </pre>
*
- * It follows immediately from the contract for <tt>compare</tt> that the
- * quotient is an <i>equivalence relation</i> on <tt>S</tt>, and that the
- * imposed ordering is a <i>total order</i> on <tt>S</tt>. When we say that
- * the ordering imposed by <tt>c</tt> on <tt>S</tt> is <i>consistent with
+ * It follows immediately from the contract for {@code compare} that the
+ * quotient is an <i>equivalence relation</i> on {@code S}, and that the
+ * imposed ordering is a <i>total order</i> on {@code S}. When we say that
+ * the ordering imposed by {@code c} on {@code S} is <i>consistent with
* equals</i>, we mean that the quotient for the ordering is the equivalence
* relation defined by the objects' {@link Object#equals(Object)
* equals(Object)} method(s):<pre>
* {(x, y) such that x.equals(y)}. </pre>
*
@@ -111,30 +111,30 @@
* Compares its two arguments for order. Returns a negative integer,
* zero, or a positive integer as the first argument is less than, equal
* to, or greater than the second.<p>
*
* In the foregoing description, the notation
- * <tt>sgn(</tt><i>expression</i><tt>)</tt> designates the mathematical
- * <i>signum</i> function, which is defined to return one of <tt>-1</tt>,
- * <tt>0</tt>, or <tt>1</tt> according to whether the value of
+ * {@code sgn(}<i>expression</i>{@code )} designates the mathematical
+ * <i>signum</i> function, which is defined to return one of {@code -1},
+ * {@code 0}, or {@code 1} according to whether the value of
* <i>expression</i> is negative, zero or positive.<p>
*
- * The implementor must ensure that <tt>sgn(compare(x, y)) ==
- * -sgn(compare(y, x))</tt> for all <tt>x</tt> and <tt>y</tt>. (This
- * implies that <tt>compare(x, y)</tt> must throw an exception if and only
- * if <tt>compare(y, x)</tt> throws an exception.)<p>
+ * The implementor must ensure that {@code sgn(compare(x, y)) ==
+ * -sgn(compare(y, x))} for all {@code x} and {@code y}. (This
+ * implies that {@code compare(x, y)} must throw an exception if and only
+ * if {@code compare(y, x)} throws an exception.)<p>
*
* The implementor must also ensure that the relation is transitive:
- * <tt>((compare(x, y)>0) && (compare(y, z)>0))</tt> implies
- * <tt>compare(x, z)>0</tt>.<p>
+ * {@code ((compare(x, y)>0) && (compare(y, z)>0))} implies
+ * {@code compare(x, z)>0}.<p>
*
- * Finally, the implementor must ensure that <tt>compare(x, y)==0</tt>
- * implies that <tt>sgn(compare(x, z))==sgn(compare(y, z))</tt> for all
- * <tt>z</tt>.<p>
+ * Finally, the implementor must ensure that {@code compare(x, y)==0}
+ * implies that {@code sgn(compare(x, z))==sgn(compare(y, z))} for all
+ * {@code z}.<p>
*
* It is generally the case, but <i>not</i> strictly required that
- * <tt>(compare(x, y)==0) == (x.equals(y))</tt>. Generally speaking,
+ * {@code (compare(x, y)==0) == (x.equals(y))}. Generally speaking,
* any comparator that violates this condition should clearly indicate
* this fact. The recommended language is "Note: this comparator
* imposes orderings that are inconsistent with equals."
*
* @param o1 the first object to be compared.
@@ -151,23 +151,23 @@
/**
* Indicates whether some other object is "equal to" this
* comparator. This method must obey the general contract of
* {@link Object#equals(Object)}. Additionally, this method can return
- * <tt>true</tt> <i>only</i> if the specified object is also a comparator
+ * {@code true} <i>only</i> if the specified object is also a comparator
* and it imposes the same ordering as this comparator. Thus,
- * <code>comp1.equals(comp2)</code> implies that <tt>sgn(comp1.compare(o1,
- * o2))==sgn(comp2.compare(o1, o2))</tt> for every object reference
- * <tt>o1</tt> and <tt>o2</tt>.<p>
+ * {@code comp1.equals(comp2)} implies that {@code sgn(comp1.compare(o1,
+ * o2))==sgn(comp2.compare(o1, o2))} for every object reference
+ * {@code o1} and {@code o2}.<p>
*
* Note that it is <i>always</i> safe <i>not</i> to override
- * <tt>Object.equals(Object)</tt>. However, overriding this method may,
+ * {@code Object.equals(Object)}. However, overriding this method may,
* in some cases, improve performance by allowing programs to determine
* that two distinct comparators impose the same order.
*
* @param obj the reference object with which to compare.
- * @return <code>true</code> only if the specified object is also
+ * @return {@code true} only if the specified object is also
* a comparator and it imposes the same ordering as this
* comparator.
* @see Object#equals(Object)
* @see Object#hashCode()
*/
< prev index next >