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