JDK-8009634 : TEST_BUG: sun/misc/Version/Version.java handle 2 digit minor in VM version
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.lang
  • Affected Version: hs23,7u21
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2013-03-07
  • Updated: 2014-04-07
  • Resolved: 2013-03-15
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 7
7u21Fixed
Related Reports
Relates :  
JDK-8039372 - TEST_BUG: Test sun/misc/Version/Version.java fails in 8u11 nightly
Relates :  
JDK-8010166 - TEST_BUG: fix for 8009634 overlooks possible version strings (sun/misc/Version/Version.java)
Description
Testsuite name: Regression 
Test name: sun/misc/Version/Version.java
JDK tested: jdk 7u21 b05 
OS tested: Windows 
Is it a regression: YES 
Regression introduced in: 7u21 b05 

LOG: 

#section:main
----------messages:(3/103)----------
command: main Version
reason: User specified action: run main Version 
elapsed time (seconds): 0.61
----------System.out:(4/181)----------
newVersionInfo: input=1.7.0_21-b05 output=1.7.0_21-b5
JDK version = 1.7.0_21-b5  1.7.0_21-b5
newVersionInfo: input=23.21-b01 output=23.2.0-b0
JVM version = 23.2.0-b0 23.21.0-b1
----------System.err:(13/785)----------
java.lang.RuntimeException: Unmatched version: 23.2.0-b0 vs 23.21.0-b1
	at Version.main(Version.java:56)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:601)
	at com.sun.javatest.regtest.MainWrapper$MainThread.run(MainWrapper.java:96)
	at java.lang.Thread.run(Thread.java:722)

JavaTest Message: Test threw exception: java.lang.RuntimeException: Unmatched version: 23.2.0-b0 vs 23.21.0-b1
JavaTest Message: shutting down test

STATUS:Failed.`main' threw exception: java.lang.RuntimeException: Unmatched version: 23.2.0-b0 vs 23.21.0-b1
result: Failed. Execution failed: `main' threw exception: java.lang.RuntimeException: Unmatched version: 23.2.0-b0 vs 23.21.0-b1


test result: Failed. Execution failed: `main' threw exception: java.lang.RuntimeException: Unmatched version: 23.2.0-b0 vs 23.21.0-b1
Comments
No, unfortunately. I wrote the regex to correspond to the description in the testcase: n.n.n[_uu[c]][-<identifer>]-bxx. I had mistakenly interpreted the description to mean that identifier could only be a set word. Won't the above string trick the original to use the 2nd b37 though? I.e. if the string was 24.0-b37-internal-201303141810.amurillo.hs24-b38-set-ver-fastdebug the build would be reported incorrectly? (just making sure I understand how to interpret this for my follow up)
15-03-2013
Did you test the fix with internal VM builds? For example, from JPRT builds which are used for Hotspot testing: 24.0-b37-internal-201303141810.amurillo.hs24-b37-set-ver-fastdebug Note, the official Hotspot VM version string is defined in hotspot/src/share/vm/runtime/vm_version.cpp : <major_ver>.<minor_ver>-b<nn>[-<identifier>][-<debug_target>] Build number always follows major.minor numbers. And identifier can be any string, for example in this case: internal-201303141810.amurillo.hs24-b37-set-ver Thanks, Vladimir
15-03-2013
I've moved this to core-libs/java.lang for now and Rob has agreed to take it and fix the test. Note that this is not a regression, it's just that the test needs to be updated to take account of the new version syntax.
12-03-2013
Seems wrong that sun.misc isn't a core-libs category. Don't know who will see this in other-libs/other
07-03-2013
Similar to the problem we had when we first hit a three-digit build number.
07-03-2013
I took a look at the JVM version parsing code in Version.java and it expects the hotspot version to be nn.n: // HSX has nn.n (major.minor) version major = Integer.valueOf(version.substring(0, 2)).intValue(); minor = Character.digit(cs.charAt(3), 10); cs = cs.subSequence(4, cs.length()); It can't handle 21, I guess we never had a 2 digit minor version for hotspot. This is not a hotspot/build bug.
07-03-2013
hsx version for 7u21 was updated to 23.21-b01 (new system for 7u where hsx minor version matches JDK update version)
07-03-2013
Take a close look at this output from the test: ----------System.out:(4/181)---------- newVersionInfo: input=1.7.0_21-b05 output=1.7.0_21-b5 JDK version = 1.7.0_21-b5 1.7.0_21-b5 newVersionInfo: input=23.21-b01 output=23.2.0-b0 JVM version = 23.2.0-b0 23.21.0-b1 The JVM input of "23.21-b01" is morphed into "23.2.0-b0" which is clearly wrong so the comparison of "23.2.0-b0" and "23.21.0-b1" don't match.
07-03-2013
It seems somebody forgot to change version number.
07-03-2013