
<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Dec 1, 2010, at 6:28 AM, Alan Bateman wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div>Kelly O'Hair wrote:<br><blockquote type="cite">A revised proposal...<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Still called "jdk.release".<br></blockquote><blockquote type="cite">But if people really think "jdk.properties" sounds ok, at least the names are unique and won't conflict.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"> <a href="http://cr.openjdk.java.net/~ohair/openjdk7/jdk_release2/webrev/">http://cr.openjdk.java.net/~ohair/openjdk7/jdk_release2/webrev/</a><br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">A Linux 64bit build should result in a jdk.release file that looks something like:<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">jdk.os.name = Linux<br></blockquote><blockquote type="cite">jdk.os.version = 2.6<br></blockquote><blockquote type="cite">jdk.os.arch = amd64<br></blockquote><blockquote type="cite">jdk.java.version = 1.7.0<br></blockquote><blockquote type="cite">jdk.vm.cfg.files = jre/lib/amd64/jvm.cfg<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">-kto<br></blockquote>I think jdk.release is better given the intended usage.<br><br>I'm not sure about the reference to jvm.cfg as that file comes with a health warning:<br><br># List of JVMs that can be used as an option to java, javac, etc.<br># Order is important -- first in this list is the default JVM.<br># NOTE that this both this file and its format are UNSUPPORTED and<br># WILL GO AWAY in a future release.<br><br></div></blockquote><div><br></div>Ah, but I should be able to point people at DrainO, even though it's poison. ;^)</div><div>I'm just providing a reference to a file (if it exists) that could help explain what VM's are available.</div><div>If there was an official "vm.release" file, I could refer to that. But I don't see one. :^(</div><div><br></div><div>Maybe my name should be jdk.vm.info.files and for now point at these cfg files, but ask for a</div><div>more formal vm identification file?</div><div><br><blockquote type="cite"><div>I wonder if jdk.vm.<type>[.<subtype>] = <extra-options> could work instead, eg:<br><br>jdk.vm.hotspot.client = -client<br><br>IBM might ship with something like:<br><br>jdk.vm.j9 =<br><br>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.<br><font class="Apple-style-span" color="#000000"><font class="Apple-style-span" color="#144FAE"><br></font></font></div></blockquote><div><br></div>But now the actual names become vm specific instead of the values. And some of those names are</div><div>trademarked. And it starts getting more complicated to generate even for hotspot.</div><div><br></div><div>What I'm discovering is that in general, the jdk build process really doesn't know too much about the</div><div>VMs and particularly what VM gets used in what situation, or even what kind of VM it is.</div><div>There is a benefit to that, but it makes the above hard to determine in a reliable way.</div><div><br></div><div>Just providing a reference(s) to VM specific information files has some big benefits.</div><div>And if jvm.cfg is not supported, maybe we need one that is? Or a vm.release file?</div><div><br></div><div><blockquote type="cite"><div>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).<br></div></blockquote><div><br></div>It will be space delimited.</div><div>My expectation is that anyone looking at these jvm.cfg files had better check to see if they exist before reading</div><div>them in, just in case, but the way our current build process is working does not make this easy.</div><div>For Oracle, only Solaris ever delivers both in the same install image, although I don't know what all the</div><div>other various OpenJDK install images look like. It is a nasty issue the way the 64-bit image can be overlayed (or not)</div><div>over the 32bit one.</div><div><br></div><div>I have some ideas about changing the build process that could fix this, but it's a different subject.</div><div><br></div><div>-kto</div><div><br><blockquote type="cite"><div><br>-Alan.<br></div></blockquote></div><br></body></html>