EnumSet.class serialization broken - twice - JDK-8227368

Peter Levart peter.levart at gmail.com
Tue Jul 9 08:45:45 UTC 2019


Hi Stuart,

On 7/9/19 1:57 AM, Stuart Marks wrote:
> 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.

Right, I agree.

>
> 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.

This is already in the webrev.01 changeset. webrev.02 is an attempt to 
sneak the change without being visible in the serialized-form.html.

>
> 2. Create draft CSR.

I'll try that right away.

Regards, Peter

>
> 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
>>



More information about the core-libs-dev mailing list