RFR 8009736: Comparator API cleanup

[Brian Goetz]

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.

On 6/14/2013 5:26 PM, Tom Hawtin wrote:
> On 14/06/2013 11:07, Paul Sandoz wrote:
>>
>> On Jun 13, 2013, at 7:28 PM, Tom Hawtin <tom.hawtin at oracle.com> wrote:
>>
>>> On 12/06/2013 17:36, Paul Sandoz wrote:
>>>
>>>> "The returned comparator is serializable and does not permit null arguments when comparing objects".
>>>
>>> Being Serializable at all is odd. It brings the previously
>>> implementation-dependent name and fields into the API spec.
>>>
>>
>> That is, alas, inherently the nature of serialization. Collections are serializable, some collections take Comparator instances on construction (e.g. TreeSet).
>
> It follows that reasonably some Comparators should be Serializable, but
> it does not follow that all Comparators are necessarily Serializable.
> You can have, say, a TreeSet<MappedByteBuffer> but it isn't necessarily
> [runtime] serialisable.
>
> As is Comparators$NullComparator will appear in the spec for all time. I
> want to check that we're happy with this.
>
>> I dunno what to say except "serialization is bad! i wish it were never in the JDK" :-)
>
> And the same for most of the rest of the Java Class Library*.
>
> Tom
>
> *There are parts of String which I think are okay.
>