On 11/04/2014 1:42 AM, Alejandro E Murillo wrote:
Hi David, thanks for the feedback, see below
On 4/9/2014 8:38 PM, David Holmes wrote:
Hi Alejandro,
Given we have to maintain the JDK version information in two places
(top level repo and hotspot repo) wouldn't it have been simpler to
keep hotspot_version file and HOTSPOT_RELEASE_VERSION and simply set
the major/minor/build values to match those of the JDK version?
The file is still used, just renamed as only jdk info is in there.
HOTSPOT_RELEASE_VERSION was also kept, we just don't get the
major,minor,micro and build number
from it anymore, mainly it is now set very similar to the
JDK_RELEASE_VERSION (plus other values),
and that format it's not fixed as it used to be for hotspot express.
Those values (major,minor,micro and build number)
are already defined in the makefiles, so we just pass them to
vm_version.cpp, so no more parsing in it.
I still think the overall changes could have been much smaller but okay.
Thanks,
David
-----
That aside, in jdk_version file hotspot copyright should now be 2014
will fix that
*/vm.make:
This line is way too long.
! VM_VER_DEFS = -DHOTSPOT_RELEASE_VERSION="\"$(HS_BUILD_VER)\""
-DJRE_RELEASE_VERSION="\"$(JRE_RELEASE_VER)\""
-DJDK_MAJOR_VERSION="\"$(JDK_MAJOR_VERSION)\""
-DJDK_MINOR_VERSION="\"$(JDK_MINOR_VERSION)\""
-DJDK_MICRO_VERSION="\"$(JDK_MICRO_VERSION)\""
-DJDK_BUILD_NUMBER="\"$(JDK_BUILD_NUMBER)\""
ok
Not clear why we suddenly need defines for all the component pieces
either. You could have kept the HS_XXX variables, just adding the
micro part.
as mentioned above, the micro part was actually added to
HOTSPOT_RELEASE_VERSION,
we just don't get those values by parsing it, so we just pass those
values to the vm_version.cpp,
since they are already defined in the makefiles. The format of the JDK
version is not that fixed.
Thanks
Alejandro
David
On 10/04/2014 10:15 AM, Alejandro E Murillo wrote:
Please review this change to make the hotspot related output produced by
"java -version"
match the corresponding JDK output:
webrev: http://cr.openjdk.java.net/~amurillo/9/8030011/
Bug: https://bugs.openjdk.java.net/browse/JDK-8030011
Note that we initially wanted to obtain more information from the repo
being built and add
it to the hotspot version output, but that will require changes in the
JPRT, so
we have decided to split the change in 2 bugs. One to make the version
match
(above webrev) and another one, an RFE, to add additional information
extracted from the repo.
Note that in the current version of vm_version.cpp, there is no error
checking in product mode,
I was suggested to make that explicit.
Release Engineering did some testing and I also ran several cases with
full and just hotspot JPRT builds.
Here is a summary of how the new output compares to the old one:
(1) Release Engineering builds (9-dev):
from jdk9-dev build:
java version "1.9.0-ea"
Java(TM) SE Runtime Environment (build
1.9.0-ea-langtools-nightly-h257-20140328-b07-b00)
Java HotSpot(TM) 64-Bit Server VM (build
1.9.0-ea-langtools-nightly-h257-20140328-b07-b00, mixed mode)
compared with what we currently have
java version "1.9.0-ea"
Java(TM) SE Runtime Environment (build
1.9.0-ea-langtools-nightly-h247-20140326-b06-b00)
Java HotSpot(TM) 64-Bit Server VM (build 25.0-b62, mixed mode)
(2) Release Engineering builds (jdk9):
java version "1.9.0-ea"
Java(TM) SE Runtime Environment (build 1.9.0-ea-b07)
Java HotSpot(TM) Server VM (build 1.9.0-ea-b07, mixed mode)
compared with what we currently have
java version "1.9.0-ea"
Java(TM) SE Runtime Environment (build 1.9.0-ea-b07)
Java HotSpot(TM) 64-Bit Server VM (build 25.0-b62, mixed mode)
(3) JPRT Full builds:
java version "1.9.0-internal"
# Java(TM) SE Runtime Environment (build
1.9.0-internal-201404091627.amurillo.jdk9-hs-ver-str-co-b00)
# Java HotSpot(TM) Server VM (build
1.9.0-internal-201404091627.amurillo.jdk9-hs-ver-str-co-b00, mixed mode)
(4) JPRT hotspot only builds:
java version "1.9.0-ea-fastdebug"
# Java(TM) SE Runtime Environment (build 1.9.0-ea-fastdebug-b06)
# Java HotSpot(TM) Server VM (build
1.9.0-internal-201404031820.amurillo.jdk9-hs-ver-str-HS-fastdebug, mixed
mode)
in this one the built VM is inserted into a promoted build bundle,
since we do not have the JDK build number info in the hotspot repo,
we can't match the build number in the JDK portion.
With the RFE mentioned above, we can extract the build info from the
repo
and add it to the hotspot portion.
I want to mention, that this may change once the new JDK version change
is implemented
but we don't know when that will be implemented yet, so we need to go
ahead with this to
get rid of the old hotspot express output. And most of these changes
will still have to be done
anyways
BTW, john Coomes and Dan Daugherty provided feedback in some pieces of
this webrev,
but I need full reviews now.
Thanks
