United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-8009634 TEST_BUG: sun/misc/Version/Version.java handle 2 digit minor in VM version
JDK-8009634 : TEST_BUG: sun/misc/Version/Version.java handle 2 digit minor in VM version

Details
Type:
Bug
Submit Date:
2013-03-07
Status:
Closed
Updated Date:
2013-12-17
Project Name:
JDK
Resolved Date:
2013-03-15
Component:
core-libs
OS:
generic
Sub-Component:
java.lang
CPU:
generic
Priority:
P2
Resolution:
Fixed
Affected Versions:
hs23,7u21
Fixed Versions:
7u25 (b02)

Related Reports
Backport:
Backport:
Backport:
Relates:

Sub Tasks

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
hsx version for 7u21 was updated to 23.21-b01 (new system for 7u where hsx minor version matches JDK update version)
                                     
2013-03-07
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. 
                                     
2013-03-07
Similar to the problem we had when we first hit a three-digit build number.
                                     
2013-03-07
Seems wrong that sun.misc isn't a core-libs category. Don't know who will see this in other-libs/other
                                     
2013-03-07
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.
                                     
2013-03-09
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
                                     
2013-03-15
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)
                                     
2013-03-15
It seems somebody forgot to change version number.
                                     
2013-03-07
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.
                                     
2013-03-07



Hardware and Software, Engineered to Work Together