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
