[8u] RFR(S): 8244548: JDK 8u: sun.misc.Version.jdkUpdateVersion() returns wrong result

[Andrew Hughes]

On 15/05/2020 14:29, Andrew Haley wrote:
> On 5/15/20 9:45 AM, Severin Gehwolf wrote:
>> So, Andrew Haley, what's the verdict on this one? There is a risk, yes.
>> Not fixing the bug seems riskier, though. Thoughts?
> 
> Thanks for the detailed explanation.
> 
> I think we have to keep sun.misc.Version working correctly but
> sacrifice binary consistency in JVM_GetVersionInfo. As long as stuff
> such as AOT compilation and class data sharing keep working I think
> we're OK. It's not great, but it's an almost-inevitable consequence of
> using a one-byte field for the minor version and bumping releases by
> 10.
> 

I see little to no risk in changing this.

Anyone using 7u261 or later, or 8u262 or later, is going to get an
overflowed minor JVM version and an overflowed upgrade JDK version even
if we do nothing at all.

What we can do is attempt to fix things in a way that doesn't change the
size of the structure, just the interpretation of its contents, as
proposed here.

Calling code that adapts to the modified version will then be able to
get the correct values. Code that doesn't will be just as broken as if
we'd made no change. Arguably, even that case will be a little better,
as with a non-zero micro value, the incorrect version will at least be
distinct from older versions.

This is for 7u & 8u, which don't have AOT compilation, so that shouldn't
be an issue.

I'll be approving this for 8u.

Thanks,
-- 
Andrew :)

Senior Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222