RFR (XS): 8148044: Remove Enum constants from EnumSet and EnumMap
claes.redestad at oracle.com
Fri Jan 22 20:30:51 UTC 2016
On 2016-01-22 19:43, Stuart Marks wrote:
> On 1/22/16 7:44 AM, Claes Redestad wrote:
>>>> It would seem the assessment that serialVersionUID is not needed when
>>>> using the serial proxy pattern might be misguided (or is this a bug in
>>> It is debate-able whether this is a test bug or not. But I think
>>> we should not change the serialVersionUID for this class, whether
>>> truly Serializable or not. Even though in practice it is not all
>>> that useful.
>>> Can you please revert the serialization parts of the change, and
>>> rerun the test? To see if still passes or fails.
>> I backed out the serial version UID change and reran the test, same
>> I dug deeper, as this is a bit vexxing...
>> While a static field does not in and of itself cause the generated
>> UID to change,
>> the private ZERO_LENGTH_ENUM_ARRAY is being accessed from
>> class, thus javac generates a package-private synthetic method
>> (access$000) which
>> will be accounted for when generating serialVersionUID. That's
>> I ran a few experiments to confirm this:
>> - Adding a package-private static method to EnumSet makes the test fail
>> - Adding any static field and the test keep passing
>> So it seems our options here are limited.
> I think this is a bug in the test (BogusEnumSet.java).
> EnumSet, a class in the runtime, should never appear in a serialized
> stream, thus it shouldn't have to declare a serialVersionUID in order
> to remain compatible with anything.
> The test deliberately attempts to create a serialized stream that
> should never occur in actual use, so the test should be responsible
> for constructing that stream properly. Unfortunately, the test doesn't
> actually construct that stream; instead it's a bunch of hex constants.
> It's tedious but not difficult to patch the constants with the
> modified value. I've appended a patch below that does this, along with
> removing EnumSet's serialVersionUID and restoring the @SuppressWarnings.
> I can post a webrev if this doesn't come through properly.
I've posted a webrev including your changes here:
If there's a preference for this version I'll push it after the weekend.
More information about the core-libs-dev