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

[Kelly O'Hair]

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