JDK-8087202 : Add support for PATCH field and remove unused fields of new version string
  • Type: Sub-task
  • Component: infrastructure
  • Affected Version: 9-repo-verona
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2015-06-11
  • Updated: 2016-08-23
  • Resolved: 2015-06-22
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 9
9Fixed
Related Reports
Duplicate :  
Relates :  
Description
This is a follow-up fix for issues pointed out in the code review for JDK-8085822. Since that changeset went into verona/stage, the problems pointed out by the code review should be resolved in verona/stage before pushing to mainline.

Alan Bateman:
Will the update_version and special_update_version fields eventually be dropped from the jvm_version_info structure?

The webrev shows a change to this comment in jvm.h:
  "Third, this file contains various I/O and network operations needed by the standard Java I/O and network APIs."
  I think this comment can be removed because those JVM_* functions were removed some time ago.

Daniel D. Daugherty:
General comment: It looks like support for the 'patch' value is not completely
    implemented through all the Makefiles. I didn't audit for this, but it's
    just my impression. 

hotspot/src/share/vm/runtime/java.cpp
    L661: void JDK_Version::fully_initialize(
    L662:     uint8_t major, uint8_t minor, uint8_t security, uint8_t update) {
    L663:   // This is only called when current is less than 1.6 and we've gotten

        Since you're ripping out vestigial version support, I think this
        function can go away since this is version 9 and newer. Don't really
        know for sure, but based on that comment...

hotspot/src/share/vm/runtime/vm_version.cpp
    L84: void Abstract_VM_Version::initialize() {
    L85:   // FIXME: Initialization can probably be removed now.
        I agree, but that would entail also removing the
        _initialized and the uses of it... Follow on bug fix? 

David Holmes:

make/*/makefiles/vm.make
  Shouldn't the -DVERSION_XX=$(VERSION_XX) definitions be taken from the VERSION_CFLAGS in spec.gmk? (Or are you still allowing for a stand-alone hotspot build?) 

hotspot/src/share/vm/prims/jvm.h
  I think this comment is way out of date:
 /* Build number is available only for RE build (i.e. JDK_BUILD_NUMBER is set to bNN)
   * It will be zero for internal builds.
  */
and can be completely removed. Even if still true, mention of an "RE build" has no place in OpenJDK sources. 

hotspot/src/share/vm/runtime/java.cpp
  I think a lot of the modified code is obsolete post Hotspot Express - which makes it hard to determine if the changes make sense. 

hotspot/test/runtime/6981737/Test6981737.java
  This test is really only valid for the new version scheme now, so it should probably be rewritten - and in that case it really isn't testing 6981737 but should be replaced by a new test for the new version format.

Comments
Also note that currently the two copies of jvm.h in hotspot/src/share/vm/prims/jvm.h and jdk/src/java.base/share/native/include/jvm.h has drifted apart. They should be identical, which means that either one (or both) of them must be updated.
11-06-2015