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.w...@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))
