RFR 8009736: Comparator API cleanup
tom.hawtin at oracle.com
Tue Jun 18 15:38:39 PDT 2013
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
On a different topic, I wonder if it's fractionally better to write the
compare method as:
a==b ? 0 :
a==null ? (nullsFirst ? -1 : 1) :
Also as this class considers all null to be a single value, I think that
should be nullFirst instead of nullsFirst.
More information about the lambda-dev