| Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
|---|---|---|---|---|---|---|
| JDK-8012494 | 7u40 | Robert Mckenna | P2 | Closed | Fixed | b22 |
| JDK-8010363 | 7u21 | Robert Mckenna | P2 | Closed | Fixed | b08 |
It would appear that the JDK & JVM versions are actually irreconcilable (at least in any readable manner) and the previous fix neglects to take the following types of version strings into account:
24.0-b37-internal-201303141810.amurillo.hs24-b37-set-ver-fastdebug
1.7.0-internal-201303141817.amurillo.hs24-b36-jdk7u14-b-b00
I had incorrectly interpreted possible values for "identifier". In addition to that, the original code would actually interpret the HS string above incorrectly, using the 2nd occurance of b37 instead of the first.
The best thing to do at this point would be to separate the version parsing code for HS & the JDK.
24.0-b37-internal-201303141810.amurillo.hs24-b37-set-ver-fastdebug
1.7.0-internal-201303141817.amurillo.hs24-b36-jdk7u14-b-b00
I had incorrectly interpreted possible values for "identifier". In addition to that, the original code would actually interpret the HS string above incorrectly, using the 2nd occurance of b37 instead of the first.
The best thing to do at this point would be to separate the version parsing code for HS & the JDK.
- backported by
-
JDK-8010363 TEST_BUG: fix for 8009634 overlooks possible version strings (sun/misc/Version/Version.java)
-
- Closed
-
-
-
- Closed
-
- relates to
-
JDK-8009634 TEST_BUG: sun/misc/Version/Version.java handle 2 digit minor in VM version
-
- Closed
-