RFR 8009736: Comparator API cleanup
brian.goetz at oracle.com
Fri Jun 14 17:56:10 PDT 2013
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*.
> *There are parts of String which I think are okay.
More information about the lambda-dev