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

[Kelly O'Hair]

On Dec 1, 2010, at 6:28 AM, Alan Bateman wrote:

> Kelly O'Hair wrote:
>> A revised proposal...
>>
>> Still called "jdk.release".
>> But if people really think "jdk.properties" sounds ok, at least the  
>> names are unique and won't conflict.
>>
>> http://cr.openjdk.java.net/~ohair/openjdk7/jdk_release2/webrev/
>>
>> A Linux 64bit build should result in a jdk.release file that looks  
>> something like:
>>
>> jdk.os.name = Linux
>> jdk.os.version = 2.6
>> jdk.os.arch = amd64
>> jdk.java.version = 1.7.0
>> jdk.vm.cfg.files = jre/lib/amd64/jvm.cfg
>>
>> -kto
> I think jdk.release is better given the intended usage.
>
> I'm not sure about the reference to jvm.cfg as that file comes with  
> a health warning:
>
> # List of JVMs that can be used as an option to java, javac, etc.
> # Order is important -- first in this list is the default JVM.
> # NOTE that this both this file and its format are UNSUPPORTED and
> # WILL GO AWAY in a future release.
>

Ah, but I should be able to point people at DrainO, even though it's  
poison. ;^)
I'm just providing a reference to a file (if it exists) that could  
help explain what VM's are available.
If there was an official "vm.release" file, I could refer to that. But  
I don't see one. :^(

Maybe my name should be jdk.vm.info.files and for now point at these  
cfg files, but ask for a
more formal vm identification file?

> I wonder if jdk.vm.<type>[.<subtype>] = <extra-options> could work  
> instead, eg:
>
> jdk.vm.hotspot.client = -client
>
> IBM might ship with something like:
>
> jdk.vm.j9 =
>
> For the tool maker, if he doesn't recognize any of the VM types then  
> he launches "java" without any VM specific options. If he recognizes  
> one or more of the types then he's got the launcher option to select  
> that VM type and he can add the VM options that he knows are  
> applicable to that VM type.
>

But now the actual names become vm specific instead of the values. And  
some of those names are
trademarked. And it starts getting more complicated to generate even  
for hotspot.

What I'm discovering is that in general, the jdk build process really  
doesn't know too much about the
VMs and particularly what VM gets used in what situation, or even what  
kind of VM it is.
There is a benefit to that, but it makes the above hard to determine  
in a reliable way.

Just providing a reference(s) to VM specific information files has  
some big benefits.
And if jvm.cfg is not supported, maybe we need one that is? Or a  
vm.release file?

> One other thing that isn't clear to me how this will work when we  
> overlap a 64-bit image over a 32-bit. I assume that jdk.release will  
> get overridden. If you keep jdk.vm.cfg.files when I assume that will  
> be an issue with the 64-bit overlap too as the value in that case  
> will need to be "jre/lib/i386/jvm.cfg, jre/lib/amd64/ 
> jvm.cfg" (assuming that comma is the delimiter).

It will be space delimited.
My expectation is that anyone looking at these jvm.cfg files had  
better check to see if they exist before reading
them in, just in case, but the way our current build process is  
working does not make this easy.
For Oracle, only Solaris ever delivers both in the same install image,  
although I don't know what all the
other various OpenJDK install images look like. It is a nasty issue  
the way the 64-bit image can be overlayed (or not)
over the 32bit one.

I have some ideas about changing the build process that could fix  
this, but it's a different subject.

-kto

>
> -Alan.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/build-dev/attachments/20101201/865924fc/attachment.htm>