On Dec 1, 2010, at 7:20 PM, David Holmes wrote:
Kelly O'Hair said the following on 12/02/10 07:26:
On Dec 1, 2010, at 12:56 PM, Ulf Zibis wrote:
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?
...
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.
Exactly. The whole Eclipse problem that motivated this stemmed from
the fact that they wanted a way to identify the JVM, given a "java"
command, without having to launch the VM and parse some version
output. This is what this simple file aims to do.
But I'm inclined to think that this isn't worth the effort any more,
particularly as all it does is open a can of worms regarding what
info different environments might want about the VM - and given the
original problem that motivated this is moot for a number of reasons.
The "original" problem was that we provided no easy way to identify
what jdk or vm release you had without
actually executing native binary code. Eclipse was just one instance
of the lack of this mechanism.
The fact that Eclipse may not need to use that one specific hotspot VM
option in jdk7 doesn't mean that a new
one won't crop up, or that some other tool has or will run into a
similar issue.
(Although it always struck me as odd that this wasn't considered a
serious VM bug, the fact that Eclipse or any Java
app would not start up without an extra -X option seems like a
serious flaw. This wasn't just an optional -X option
to improve performance as I recall. But that's a separate issue.)
So forget about the Eclipse situation. I could use this jdk.release
file to manage multiple jdk images and also
verify jdk images are the correct ones. And I'm pretty sure other java
launchers could use it to optimize the
launching of their apps. So I do think it is worth some effort, or I
wouldn't have started this painful review.
However, I am trying to limit my scope here, as much as organizing
options might be valuable, that goes
well beyond anything I wanted to accomplish.
-kto
David
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
