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

[Ulf Zibis]

Am 01.12.2010 22:26, schrieb Kelly O'Hair:
>
> 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'.

Hm ok, I couldn't imagine that.
Is that valid for _all_ options of the java launcher?
E.g. "-X", which seems to simply output the content of bin\client\Xusage.txt.

I think, it's time to refactor the java launcher, to provide the output for NONE, '-?', '-help', 
'-version', '-X', '-XX' in a _cheap way_!!

The raw information of those commands could be hosted at a standardized location, so all would be 
happy, even those, who don't want/can execute the java launcher. I suggest following sections (and 
maybe names):
version.txt
usage.txt
Xusage.txt
XXusage.txt

optionally we could have (alternatively in java properties format):
versions.txt (note the final 's');    (just the strings for java_language, java_lib, vm[s], os, 
arch, etc. in separated lines)
options.txt     (in somehow standardized format)
Xoptions.txt                 "
XXoptions.txt                 "

At least the names should be universal for JDK and JRE !!

>
>>
>>>
>>> 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.
>
Ok, you want to help for unclear/broken installations. Maybe a kind of "a bottomless pit".
So if you find a java-image-like bunch of files somewhere you accordingly expect the virus vendor's 
name in "jdk.release" file ;-)

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

Thanks for clarification.
... But I'm still missing a _reliable, future-proof AND simple_ solution for the original problem, 
namely how to find out, which options are available/appropriate.

-Ulf