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

[Kelly O'Hair]

On Dec 1, 2010, at 7:27 AM, Ulf Zibis wrote:

> 1.) naming:
> a: What would be the name for the JRE installation, "jre.release" ?

That would be a separate RFE in my opinion, easy to do but my primary  
target was the jdk for now.

> 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.

I have been trying to limit the scope of this as much as possible,  
this seems to be making it much
more complicated than I want or I think anyone needs.

>
> 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

It's a older historic name, I did not pick it. It is up to the VM  
teams to change.

>
> 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

How much more simple can you get name=value? Very platform neutral.
And what are these "real options" and "original spellings"? Can you  
clarify?

> - could not be mixed with java runtime properties

Why not? If the names do not overlap, don't start with "os." or  
"java.", what is the harm?

>
> 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.

I'm completely lost here, what does the above have to do with my  
jdk.release proposal?
Seems like you are talking about a completely different thing.

>
> 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

Actually "Oracle Corporation", but again, not sure what this has to do  
with the jdk.release proposal now that
I have removed the vendor values from it.
I do agree about COMPANY, just haven't felt like we had much choice in  
the matter. :^(

However, the default OpenJDK build (from the top) will probably only  
say "Oracle Corporation" on the java
specification vendor properties.
I'm pretty sure that windows COMPANY value,  java.vendor and  
java.vm.vendor will default to "N/A" or
whatever the make variable COMPANY_NAME says. Or if the build is done  
with an explicit 'make OPENJDK=true'.
The top Makefile will make an early check to see if OPENJDK should be  
set to true, not sure about all Makefiles.

-kto

>
> 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
>>
>>