Finding max or min of exactly two objects

[Brian Goetz]

When we did Lambda, we made a few mistakes in the category of adding 
default methods to some "highly abstract" types, such as 
Function::andThen.  You were there; these were well-intentioned, but we 
neglected to think sufficiently about the consequences for subclasses.  
For example:

     interface Function<T,U> {
         U apply(T t);

         <V> default Function<T, V> andThen(Function<U,V> g) { ... }
     }

seems fine, but then when you extend it:

     interface UnaryOperator<T> extends Function<T,T> {
     }

you kind of lose, because you can't compose _unary operators_ using 
Function::compose.  And if you try to refine it:

     interface UnaryOperator<T> extends Function<T,T> {
         default UnaryOperator<T> andThen(UnaryOperator<T> g) { ... }
     }

you end up overloading, not overriding the method, in a way that clients 
cannot distinguish: `f.andThen(lambda)` will likely not be able to 
distinguish between the overloads, because they have the same shape.  
Ooops.

So with that as background, I am very cautious to consider adding 
methods to Comparable, because it is a highly abstract type that was 
designed for extension, and the risk of the above kind of clash seems 
"not low".

Comparator seems less risky, because it is not designed to be extended 
by domain objects, but instead functions more like a type class in 
Haskell -- it is behavior _about_ a type, defined from the outside.  And 
Haskell would agree with you that this move is sensible; here's 
Haskell's `Ord` (like Comparator), which extends `Eq` (providing equality.)

class  (Eq a) => Ord a  where
     compare              :: a -> a -> Ordering
     (<), (<=), (>), (>=) :: a -> a -> Bool
     max, min             :: a -> a -> a

     compare x y = if x == y then EQ
                   -- NB: must be '<=' not '<' to validate the
                   -- above claim about the minimal things that
                   -- can be defined for an instance of Ord:
                   else if x <= y then LT
                   else GT

     x <= y = case compare x y of { GT -> False; _ -> True }
     x >= y = y <= x
     x > y = not (x <= y)
     x < y = not (y <= x)


         -- These two default methods use '<=' rather than 'compare'
         -- because the latter is often more expensive
     max x y = if x <= y then y else x
     min x y = if x <= y then x else y
     {-# MINIMAL compare | (<=) #-}

The `compare` method is like our Comparator method, just returning a 
three-valued enum rather than an int.  (Haskell has a cool feature here, 
where you can define all the methods in terms of others, and then you 
can override whichever ones make sense to break the cycles.  The MINIMAL 
annotation says "if you provide either compare or <=, you're good."  I 
wish we had this for interfaces with default methods.)  It then proceeds 
to derive `min` and `max` from `<=` (which might itself be derived from 
`compare`.)

OK, "comparative languages" lesson over, back to your point. There are 
two ways to get where you want: a static method that takes a comparator 
and the operands (`Comparator.max(c, a, b)`), or a default method on 
Comparator (`c.max(a, b)`).  (You say "add simple static methods ... to 
Comparator" but I think you mean to put the word `static` elsewhere in 
that sentence.)

I am receptive to the idea of extending Comparator here, but would want 
to think about it more to feel out potential mistakes like the `andThen` 
one above.  But your point is solid: a "comparator" is also a "maxxer" 
and a "minner" (neither of those are words, and if they were, are 
probably spelled wrong), and that is a natural place to locate such 
behavior.




On 5/13/2025 10:12 AM, Tagir Valeev wrote:
> Hello!
>
> Several times already when writing Java programs, I stumbled with a 
> simple task: given two objects with natural order, find the maximal of 
> them. The algorithm I need could be formulated like this:
>
>     <T extends Comparable<T>> T max(T a, T b) {
>         return a.compareTo(b) > 0 ? a : b;
>     }
>
> Writing manually compareTo >= 0 looks too verbose, not very readable 
> and error-prone: one has to mention both objects twice, and it's 
> possible to mix > with <. I can surely add a method mentioned above to 
> a utility class in my project and use it everywhere. However, I feel 
> that it deserves a place in the standard library.
>
> The alternatives we have now:
> BinaryOperator.maxBy(Comparator.<T>naturalOrder()).apply(a, b);
> This speaks clearly about the intent (we'd like to get the maximum and 
> we write 'maxBy') but very wordy.
>
> Stream.of(a, b).max(Comparator.naturalOrder()).get();
> Also clear and a little bit shorter, but has an unnecessary Optional 
> in-between (we know that we have at least one element, so the result 
> is always present) and we have to mention the comparator. Finally, it 
> might be much less efficient than expected.
>
> Probably we can add simple static methods `max` and `min` either to 
> the `Comparator` interface, or to `java.util.Objects`? Such methods 
> would complement methods from the `Math` class for numbers. In 
> addition, having default methods `max` and `min` in the `Comparator` 
> interface would also be nice:
>
> String bigger = String.CASE_INSENSITIVE_ORDER.max("Hello", "world");
>
> What do you think? Can we proceed with such an enhancement?
>
> With best regards,
> Tagir Valeev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250513/bf4e7c6d/attachment-0001.htm>