On Dec 1, 2010, at 11:15 AM, Ulf Zibis wrote:
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 ?
'java -options' would launch a VM, I'm trying to avoid that. If some
tool vendors can do that, then they
could write a small java class file that does exactly what they want
and run that.
Besides the minor performance hit, in my situation maybe someone
installed or copied over the wrong jdk, say a Linux jdk image
onto a Solaris machine, the java command will fail in some strange way.
I'd like to know what kind of jdk image I have before I start it up.
Dito for having a x86_64 jdk image and running it on a 32bit OS.
Or maybe my launcher is smart enough to know that a jdk1.7.0 version
will not work on the system and wants to
avoid even trying to starting it up, using a jdk1.6.0 image instead.
I am more after something like the /etc/*release files on a Solaris or
Linux system.
-kto
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
