RFR 8009736: Comparator API cleanup

[Tom Hawtin]

On 17/06/2013 19:37, Henry Jen wrote:

> I am not sure what do you mean by API serial proxy, my understanding of the concern is that we want to hide the implementation detail from serialization. Seems to me, that is the same as we distill the implementation to it's essential minimum. Isn't it? For this case, it would be a boolean and the original Comparator, and that's the latest implementation.

A serial proxy is a class that which the serialisation mechanism works 
on to work out what to write into the stream, but isn't the actual 
working class. When serialised the working class returns a serial proxy 
from its writeReplace, which is actually serialised. When deserialised 
the serial proxy replaces itself with a working class from readResolve.

So for example, if we find out HotSpot works better if we have two 
different implementations for returning sign +1 and -1 (because that 
determines where the calling code immediately jumps to), then we can do 
that with three classes, one of which being a serial proxy with the 
original implementation name and fields. Similarly if we found that the 
target comparator was almost always the same type and wanted to combine 
the comparators when used in sequence, we could have a serial proxy 
handle that.

On a different topic, I wonder if it's fractionally better to write the 
compare method as:

             return
                 a==b ? 0 :
                 a==null ? (nullsFirst ? -1 : 1) :
                 real.compare(a, b);

Also as this class considers all null to be a single value, I think that 
should be nullFirst instead of nullsFirst.

Tom