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

[Ulf Zibis]

1.) naming:
a: What would be the name for the JRE installation, "jre.release" ?
b: As we have a bin\client\Xusage.txt, we additionally could have:
- bin\usage.txt
- bin\client\XXusage.txt
- bin\Jrocket\XXusage.txt
- etc.
and maybe (without help text, but with well defined syntax):
- bin\options.txt
- bin\client\Xoptions.txt
- bin\client\XXoptions.txt
- etc.
or specify the syntax of the left column of the *usage.txt files.
The bin directory would be a good location, as it is well known for the java.exe.

2.) jre/lib/xxx/jvm.cfg:
- the naming "cfg" is confusing. It is normaly used for user configurable settings, but there is 
nothing to configure.
- e.g. netbeans/etc/netbeans.conf

3.) Don't use java properties syntax:
- the launcher, here Eclipse, should know/maintain the valid matching from the properties to the 
available options.
- so make it quite simple: just list the real options + valid values in their original spelling
- could not be mixed with java runtime properties

4.) "properties" file vs command line option or dll usage interface:
- the interpretation of the usage/options.txt files should be optional for a launcher, but not 
guaranteed to work.
- I propose additional command line options to output the valid choices
    (=content of the maybe existent hidden options.txt file) as java -X does today:
-- just execute: java -options -Xoptions -XXoptions -version:minOS -version:java -version:lib 
-version:vm (including the build)
-- in case of multiple VMs: java -Jrocket -XXoptions or -XXoptions:Jrocket
-- to test a single option or any combination, execute: java -? -XXMaxPermSize[=64] and return 0 | 1 
| -1
- for the dll there should be a well defined interface/api to retrieve the version + options values.
- using command line options or dll api for that purpose is common practice for many other 
applications, at least in Windows.

5.) Windows DLL/EXE COMPANY value:
- we should use the valid "Oracle"
- applications, which rely on this, should be updated, as well, as they should, if there is a new 
java version/build with new/dropped options

My cents ...

-Ulf



Am 01.12.2010 02:34, schrieb Kelly O'Hair:
> 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
>
>