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

[Kelly O'Hair]

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