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

[Ulf Zibis]

Am 01.12.2010 17:43, schrieb Kelly O'Hair:
>
>>
>> 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
or better: java -n[othing] -XXMaxPermSize[=64] for do nothing, just check the syntax.
>> - 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.

If I understand correct, your proposal should "make life easier" for application launcher developers.
Isn't it easier to just run "java -options" etc. instead of maintaining the names of "jdk.release", 
"jre.release" + opening a file + parsing the java properties syntax + again opening another 
"jvm.cfg" file + parsing a different syntax + matching the retrieved information with potential 
valid to be maintained option strings ?

Addition:
The retrieval via -options -XXoptions -version:java etc. could be subject of another CR, but given 
the information from the suggested bin[/vmtype]/*options.txt files, this should be more simple and 
easy to maintain.

-Ulf