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

[Ulf Zibis]

Am 01.12.2010 17:43, schrieb Kelly O'Hair:
>
> On Dec 1, 2010, at 7:27 AM, Ulf Zibis wrote:
>
>> 1.) naming:
>> a: What would be the name for the JRE installation, "jre.release" ?
>
> That would be a separate RFE in my opinion, easy to do but my primary target was the jdk for now.

Maybe, but having the same file name for all distributions IMHO is better, and "jdk.release" would 
sound strange for JRE, JEE, ME, or other vendors different naming. Maybe something like 
"version.properties".

>
>> b: As we have a bin\client\Xusage.txt, we additionally could have:
>> - bin\usage.txt
>> - bin\client\XXusage.txt
>> - bin\Jrocket\XXusage.txt
>> - etc.
>> and maybe (without help text, but with well defined syntax):
>> - bin\options.txt
>> - bin\client\Xoptions.txt
>> - bin\client\XXoptions.txt
>> - etc.
>> or specify the syntax of the left column of the *usage.txt files.
>> The bin directory would be a good location, as it is well known for the java.exe.
>
> I have been trying to limit the scope of this as much as possible, this seems to be making it much
> more complicated than I want or I think anyone needs.

Is a single "bin\options.txt" or "bin\version.properties" more complicated as "jdk.release" ?
The other suggestions could be seen as additional sugar for the future.
I think, the neighbourhood to the java.exe is reasonable (no "cd .." is needed), and additionally 
fits better for future enhancements.

>
>>
>> 2.) jre/lib/xxx/jvm.cfg:
>> - the naming "cfg" is confusing. It is normaly used for user configurable settings, but there is 
>> nothing to configure.
>> - e.g. netbeans/etc/netbeans.conf
>
> It's a older historic name, I did not pick it. It is up to the VM teams to change.
But anyway, if you refer to it in "jdk.release", you need to maintain it, if the historic name would 
be updated.
Additionally it is more close to the below preferred "original spellings"-syntax than to the java 
properties syntax. In mixed case, the application launcher must be able to parse both.

>
>>
>> 3.) Don't use java properties syntax:
>> - the launcher, here Eclipse, should know/maintain the valid matching from the properties to the 
>> available options.
>> - so make it quite simple: just list the real options + valid values in their original spelling
>
> How much more simple can you get name=value? Very platform neutral.
> And what are these "real options" and "original spellings"? Can you clarify?
I mean strings like '-server', ' -ea[:<packagename>...|:<classname>]', '-Xms<size>', 
'-XXMaxPermSize=<size>', etc..
Aren't they platform neutral too ?
In case of
'jdk.java.version = 1.7.0' + 'jdk.vm.cfg.files = jre/lib/amd64/jvm.cfg' (in jdk.release) +
'-hotspot ALIASED_TO -client' (in jvm.cfg),
JDK _and_ application launcher developers need to maintain a matching table to the valid list of the 
"real options".

>
>> - could not be mixed with java runtime properties
>
> Why not? If the names do not overlap, don't start with "os." or "java.", what is the harm?
Well ok, this would be additional sugar.

>
>>
>> 4.) "properties" file vs command line option or dll usage interface:
>> - the interpretation of the usage/options.txt files should be optional for a launcher, but not 
>> guaranteed to work.
>> - I propose additional command line options to output the valid choices
>>   (=content of the maybe existent hidden options.txt file) as java -X does today:
>> -- just execute: java -options -Xoptions -XXoptions -version:minOS -version:java -version:lib 
>> -version:vm (including the build)
>> -- in case of multiple VMs: java -Jrocket -XXoptions or -XXoptions:Jrocket
>> -- to test a single option or any combination, execute: java -? -XXMaxPermSize[=64] and return 0 
>> | 1 | -1
or better: java -n[othing] -XXMaxPermSize[=64] for do nothing, just check the syntax.
>> - for the dll there should be a well defined interface/api to retrieve the version + options values.
>> - using command line options or dll api for that purpose is common practice for many other 
>> applications, at least in Windows.
>
> I'm completely lost here, what does the above have to do with my jdk.release proposal?
> Seems like you are talking about a completely different thing.

If I understand correct, your proposal should "make life easier" for application launcher developers.
Isn't it easier to just run "java -options" etc. instead of maintaining the names of "jdk.release", 
"jre.release" + opening a file + parsing the java properties syntax + again opening another 
"jvm.cfg" file + parsing a different syntax + matching the retrieved information with potential 
valid to be maintained option strings ?

>
>>
>> 5.) Windows DLL/EXE COMPANY value:
>> - we should use the valid "Oracle"
>> - applications, which rely on this, should be updated, as well, as they should, if there is a new 
>> java version/build with new/dropped options
>
> Actually "Oracle Corporation", but again, not sure what this has to do with the jdk.release 
> proposal now that
IIRC, the original problem was, that the Eclipse launcher humbled about "Oracle ..." instead of "Sun 
...".

-Ulf