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

[Ulf Zibis]

Am 01.12.2010 20:38, schrieb 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.

The java executable will be executed anyway by Eclipse launcher, at least on *nix (and probably on Mac):
"On *nix, in case (1) we exec "java -version" and look for the string "Java HotSpot(TM)" or 
"OpenJDK" in the result."
But I wonder, if "java -version" or "java -options" would launch the VM, if there is no java class 
to be executed

> 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.

In this case, the VM indeed must be launched, and twice, for the version/options info to be 
retrieved, and later for the real application.

>
> 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.

The same problem you would have, if you had copied a wrong firefox image onto a Solaris machine and 
click on a web link in a document or your email client, the referring to firefox will fail in some 
strange way.
IMO such situations should not be managed by the jdk image itself, but from the installer, which 
should verify the correct machine.

> 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.
Dito installer problem.

> 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.
Dito launcher's installer problem.

>
> I am more after something like the /etc/*release files on a Solaris or Linux system.

But yes, those scenarios could be improved, but IMHO smarter with something like "java 
-version:java", (or interpreting the existing "java -version" output, like Eclipse does), ... and - 
more important - would it solve the original problem, i.e. checking if some exotic option is available.
And think about future changes about another exotic parameters. Would vm.name=hotspot + 
jdk.java.version=1.7.0 be enough to serve this?

If my application wants to zip something, should it look for some "zip.release" file to estimate, if 
some rare option, let's say deflate64 compression, would be available. No, it should find the info 
in the zip.exe or zip.dll file, by some standardized api or by using GetFileVersionInfo on Windows.

And last ... should we have a "jdk.javac.release" file too some day?

-Ulf