RFR 8009736: Comparator API cleanup

[Henry Jen]

On Jun 17, 2013, at 9:36 AM, Tom Hawtin <tom.hawtin at oracle.com> wrote:

> On 15/06/2013 01:56, Brian Goetz wrote:
>> Yeah, but once you make one not-serializable, there's no way to
>> un-not-serializable it.  (Serializable is a misnomer; really what we
>> have is the ability to say "not serialization-hostile.")  So if any ever
>> need to be serializable, we either need to make them all so, or have two
>> versions of each factory/combinator.  Awful options all around.
> 
> Certainly for a subclassable type, making it Serializable after fcs 
> breaks expectations that can reasonably be made. I don't see your point 
> when considering "package private", private or final classes.
> 
> Like it or somewhat more likely not, once you make a type in an API 
> package serialisable it is in the public API (except Swing). Even if it 
> isn't in an API package, people (possibly the Java Class Library) will 
> still use it. As serialisation stands (and it's not likely anyone is 
> going to be keen on messing with it) you may want an API serial proxy to 
> go along with your real hidden implementation.
> 

As Brian said, we need to keep the comparator serializable. NullComparator is a simple wrapper, which is package private and we can go further make it final class.

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.

Let me know if I miss something, and I am open to better options.

Cheers,
Henry