Need reviewers and comments: 6989472: Provide simple jdk identification information in the install image
Ulf.Zibis at gmx.de
Thu Dec 2 14:45:50 UTC 2010
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
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)
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
> 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
> 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
> 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.
More information about the build-dev