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
