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

[Weijun Wang]

Updated webrev:

    http://cr.openjdk.java.net/~weijun/7107522/webrev.01/

-Max

On 11/03/2011 02:01 AM, Mandy Chung wrote:
> 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))
>