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.
http://cr.openjdk.java.net/~ohair/openjdk7/jdk_release2/webrev/
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
-kto
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
health warning:
# 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
instead, eg:
jdk.vm.hotspot.client = -client
IBM might ship with something like:
jdk.vm.j9 =
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
VM type.
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
the delimiter).
-Alan.
