RFR: 8356995: Provide default methods min(T, T) and max(T, T) in Comparator interface [v4]

Roger Riggs rriggs at openjdk.org
Fri May 23 19:00:52 UTC 2025


On Fri, 23 May 2025 12:28:36 GMT, Tagir F. Valeev <tvaleev at openjdk.org> wrote:

>> Implementation of Comparator.min and Comparator.max methods. Preliminary discussion is in this thread:
>> https://mail.openjdk.org/pipermail/core-libs-dev/2025-May/145638.html
>> The specification is mostly composed of Math.min/max and Collections.min/max specifications. 
>> 
>> The methods are quite trivial, so I don't think we need more extensive testing (e.g., using different comparators). But if you have ideas of new useful tests, I'll gladly add them.
>> 
>> I'm not sure whether we should specify exactly the behavior in case if the comparator returns 0. I feel that it could be a useful invariant that `Comparator.min(a, b)` and `Comparator.max(a, b)` always return different argument, partitioning the set of {a, b} objects (even if they are equal). But I'm open to suggestions here.
>
> Tagir F. Valeev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Make min and max generic

src/java.base/share/classes/java/util/Comparator.java line 206:

> 204:      * @since 25
> 205:      */
> 206:     default <U extends T> U max(U a, U b) {

The parameter names are o1 and o2 in the `compare` method min and max build on. 
Though a and b are used in the class javadoc example and x and y are used in the spec description.
Can we be consistent in the API?  (o1, o2) perhaps.  Someday, the parameter names *may* be more significant.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25297#discussion_r2105250452


More information about the core-libs-dev mailing list