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
