Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-8061493 JEP 223: New Version-String Scheme
  3. JDK-8087202

Add support for PATCH field and remove unused fields of new version string


    • Resolved In Build:



        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.

            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...

            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:

          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?)

          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.

          I think a lot of the modified code is obsolete post Hotspot Express - which makes it hard to determine if the changes make sense.

          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.


            Issue Links



                • Assignee:
                  amurillo Alejandro Murillo
                  ihse Magnus Ihse Bursie
                • Votes:
                  0 Vote for this issue
                  4 Start watching this issue


                  • Created: