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

[Andrew Hughes]

On 12/05/2020 09:53, Severin Gehwolf wrote:

snip...

>> In code,
>>
>> unsigned int jdk_version;
>> unsigned int update_version : 16;
>> unsigned int reserved1 : 16;
>> unsigned int reserved2;
>>
>> or, if we're wary about losing the name special_update_version, we could
> 
> special_update_version seems at least be referenced in code. So we
> would have to change those references. Given that, I'd go with reducing
> reserved1 as that doesn't seem to be used.

Yeah, can you tell I thought better of this, even as I was writing the
e-mail? ;-)

> 
>> shrink reserved1:
>>
>> unsigned int jdk_version;
>> unsigned int update_version : 16;
>> unsigned int special_update_version : 8;
>> unsigned int reserved1 : 8;
>> unsigned int reserved2;
> 
> This is what webrev 03 does:
> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8244548/03/
> 
> Does that look OK to you?

This looks ok to me.

I hadn't realised reserved1 was actually not reserved, but used for the
build number. I think it's still fine though, as I can't recall seeing
the build number go over 255 pre-GA, never mind in an update release. If
we've done over 255 weeks of build promotions before a release, we have
other problems.

Maybe a rename is in order as part of this. I can't see reserved1
referenced anywhere in the codebase, and it's actually confusing that
all the extraction code actually refers to it as the build number.
reserved2 could then simply become reserved.

> 
> Thanks,
> Severin
> 

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