Need reviewers and comments: 6989472: Provide simple jdk identification information in the install image
Alan.Bateman at oracle.com
Wed Dec 1 06:28:19 PST 2010
Kelly O'Hair wrote:
> A revised proposal...
> Still called "jdk.release".
> But if people really think "jdk.properties" sounds ok, at least the
> names are unique and won't conflict.
> A Linux 64bit build should result in a jdk.release file that looks
> something like:
> jdk.os.name = Linux
> jdk.os.version = 2.6
> jdk.os.arch = amd64
> jdk.java.version = 1.7.0
> jdk.vm.cfg.files = jre/lib/amd64/jvm.cfg
I think jdk.release is better given the intended usage.
I'm not sure about the reference to jvm.cfg as that file comes with a
# List of JVMs that can be used as an option to java, javac, etc.
# Order is important -- first in this list is the default JVM.
# NOTE that this both this file and its format are UNSUPPORTED and
# WILL GO AWAY in a future release.
I wonder if jdk.vm.<type>[.<subtype>] = <extra-options> could work
jdk.vm.hotspot.client = -client
IBM might ship with something like:
For the tool maker, if he doesn't recognize any of the VM types then he
launches "java" without any VM specific options. If he recognizes one or
more of the types then he's got the launcher option to select that VM
type and he can add the VM options that he knows are applicable to that
One other thing that isn't clear to me how this will work when we
overlap a 64-bit image over a 32-bit. I assume that jdk.release will get
overridden. If you keep jdk.vm.cfg.files when I assume that will be an
issue with the 64-bit overlap too as the value in that case will need to
be "jre/lib/i386/jvm.cfg, jre/lib/amd64/jvm.cfg" (assuming that comma is
More information about the build-dev