Need reviewers and comments: 6989472: Provide simple jdk identification information in the install image
Ulf.Zibis at gmx.de
Wed Dec 1 11:15:25 PST 2010
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 ?
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.
More information about the build-dev