EnumSet.class serialization broken - twice - JDK-8227368

[Stuart Marks]

Hi Peter,

Thanks for picking this up, for filing the bug (JDK-8227368), and developing the 
fix.

For the current release, I think we should go ahead and put in the "right" fix, 
that is, to define serialVersionUID the conventional way -- as a compile-time 
constant -- and then simply to remove the suppression of the serial warning. 
This will change the specification (because the change will appear in 
serialized-form.html), but that's OK, we have the ability to change the 
specification. Note that this will require a CSR. (Changing the svuid value 
without changing the specification would probably require a CSR anyway, since 
it's a behavioral change that affects compatibility.) Might as well fix the 
specification now and be done with it, at least for current and future releases.

The JDK 11 backport is where we should apply the static initializer. That's 
where changing the specification is more difficult. I think we should discuss 
that separately, though.

Thanks for writing the new test and updating the BogusEnumSet test.

Given that this is a fix for an incompatible change, I think this should be 
fixed as soon as possible. I've raised the priority to P3, and I've targeted 
this bug to JDK 13. We're after RDP1, but important fixes can still go in during 
RDP1 [1] until the next phase, RDP2, which begins on July 18. [2] Once this goes 
into JDK 13, it should automatically be propagated to JDK 14, with no manual 
steps necessary.

With the fairly short time frame left in JDK 13 before RDP2, it would be best to 
move as quickly as possible. If you have time to work in this immediately, 
great, but if not, that's ok; please let me know and I'll pick up any or all 
work that you don't have time to do. Regardless, I'll help out any way I can, 
such as reviewing the code and the CSR, doing testing, etc.

Next steps:

1. New changeset with constant version of EnumSet.serialVersionUID.

2. Create draft CSR.

Thanks,

s'marks


[1] http://openjdk.java.net/jeps/3

[2] http://openjdk.java.net/projects/jdk/13/




On 7/7/19 8:11 AM, Peter Levart wrote:
> On 7/7/19 4:31 PM, Peter Levart wrote:
>> On 6/29/19 2:00 AM, Stuart Marks wrote:
>>> Daniel Fuchs pointed me to a weird thing they had to do with the 
>>> serialVersionUID in one of the JMX classes:
>>>
>>> https://hg.openjdk.java.net/jdk/jdk/file/c59f36ed7b52/src/java.management/share/classes/javax/management/MBeanAttributeInfo.java#l46 
>>>
>>>
>>> Essentially the svuid for this class initialized in a static block, and its 
>>> value is conditional based on the value of some system property. I don't 
>>> think using a property is necessary for the EnumSet case. However, it does 
>>> point out something interesting, which is that if the svuid is not 
>>> initialized with a compile-time constant, and instead via a static block, the 
>>> value doesn't appear in serialized-form.html. 
> 
> Hi Stuart,
> 
> I just realized that I was reading your last statement wrong. I though it was 
> written as:
> 
> ...if the svuid is not initialized with a compile-time constant, and instead via 
> a static block, the value doesn't appear in serialized form.
> 
> And not as:
> 
> ...if the svuid is not initialized with a compile-time constant, and instead via 
> a static block, the value doesn't appear in serialized-form.html
> 
> 
> You were only concerned about the generated javadoc and not about the actual 
> "serialized form". Ok, I get it now. I have prepared webrev.02 to fix this.
> 
> 
> Regards, Peter
>