RFR 8009736: Comparator API cleanup

[Henry Jen]

On Jun 18, 2013, at 3:38 PM, Tom Hawtin wrote:
> 
> 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.
> 

Thanks, in this case, as the class is so simple and we are not likely to
have a new/different implementation after we finish it. I guess it is
good enough.

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

>From another perspective, the dataset to be compared could have more
than one null, thus nullsFirst.

EG had looked at those names and CCC is going on, so I think we will
stay with this.

Cheers,
Henry