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

[Kelly O'Hair]

On Dec 1, 2010, at 12:56 PM, Ulf Zibis wrote:

> 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

Yes, 'java -version' launches a VM, and loads up many shared libraries.

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

That's what using java -version does, you have launched the VM twice.  
It's the same thing.
You might be avoiding some class file loads with java -version, and it  
is probably quicker, but the
native VM library is loaded and run when you do a 'java -version'.

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

Sometimes formal installers are not available, and as we move forward  
into the cross-compiler build world,
even the installers might not be able to help you if you install a  
Linux PPC image on a Linux X86 system
so that you can do comparisons or partial cross compilation builds for  
PPC. Or the installer will block you
and then you are back to raw install image copies.

The installer is a great place for these checks but a formally  
installed image is not always available.
And sometimes via NFS access, the files might not even belong to the  
system you are running on.

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

I'm obviously not communicating very well.

I don't want to run 'java' because I might not be able to, and I don't  
want to use some platform specific api
to dig into binaries that may be located at any number of locations.
I'm looking for a very simple text file way to identify what I kind of  
jdk image I have.

There are numerous ways to determine this as you point out, but none  
that remove the native binary execution,
or grokking around inside binary files.

-kto

>
> -Ulf
>
>