Code review request: 7107522: sun/misc/Version/Version.java fails because of its huge build number

Mandy Chung mandy.chung at oracle.com
Wed Nov 2 18:01:22 UTC 2011


  Hi Max,

There is a bit of history here and I believe the right fix should be to 
fix the JDK_GetVersionInfo0 function in 
src/share/native/common/jdk_util.c to work with a large build number but 
treats any build number > 255 is an internal build.

This test is intended to test the native interface between the VM and 
the libs to query the VM/JDK version.  The HotSpot VM works with 
different versions of JDK and it uses this interface to determine what 
JDK version is and what capability it supports.  The build number is 
more for information. It's expected to be used only during development 
of a feature and also the build number for promoted builds (not internal 
builds) when the VM and libs have to make a coordinated change while the 
VM has to continue to work with a JDK without the new libs change.  Such 
interface was defined in the assumption of the number of promoted builds 
for a release < 256.  For internal or engineering builds, it sets the 
build number to 0.

Prior to JDK 7, the RE build version string is of this format:
    n.n.n[_uu[c]][-<identifier>]-bxx

For JDK 7, there were more than 99 builds and the format to take 3-digit 
builds.

The RE hudson nightly build goes against the RE build version string 
convention. It sets the JDK_BUILD_NUMBER to "b9" + day of year.  For 
example, January 1 is day 1 and the JDK_BUILD_NUMBER will be set to b9001.

I think we should treat the RE hudson nightly build as an internal build 
and ignore the build number (or set it to 0).

In jdk_util.c, it defines this variable:
     char build_number[4];

this should be fixed to work with any build number and set 
jdk_build_number only if it's < 255.

Hope this helps.
Mandy

On 11/02/11 04:46, Weijun Wang wrote:
> http://cr.openjdk.java.net/~weijun/7107522/webrev.00/
>
> We must stay with the fact that a build number cannot exceed 255 while 
> the system property "java.runtime.version" might show a bigger one. 
> This fix only makes sure the test always passes.
>
> If you think there should be a more proper mail list to send to, 
> please tell me.
>
> Thanks
> Max
>
> On 11/02/2011 07:41 PM, weijun.wang at oracle.com wrote:
>> *Change Request ID*: 7107522
>> *Synopsis*: sun/misc/Version/Version.java fails because of its huge 
>> build number
>>
>> === *Description* 
>> ============================================================
>> sun/misc/Version/Version.java always fails for nightly tests, because 
>> the build number from Hudson is like b9123. A normal build number 
>> should be less than 256, as shown in jvm.h:
>>
>> #define JDK_VERSION_BUILD(version) ((version&  0x000000FF))




More information about the core-libs-dev mailing list