Need reviewers and comments: 6989472: Provide simple jdk identification information in the install image

[Alan Bateman]

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.