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

Kelly O'Hair kelly.ohair at oracle.com
Tue Nov 30 23:11:38 UTC 2010 

On Nov 29, 2010, at 10:13 PM, David Schlosnagle wrote:

> On Mon, Nov 29, 2010 at 5:44 PM, Kelly O'Hair  
> <kelly.ohair at oracle.com> wrote:
>>
>> Need reviewers and comments:
>>  6989472: Provide simple jdk identification information in the  
>> install image
>>  http://cr.openjdk.java.net/~ohair/openjdk7/jdk_release/webrev/
>>
>> With JDK6 Updates we purposely resisted many rebranding changes  
>> that could impacted
>> customers, however at one point we had accidently changed the  
>> Windows DLL/EXE
>> COMPANY value thinking that no one would be looking at it.
>> We were wrong and this change cause Eclipse failures, so we are  
>> looking for a solution, see:
>>   https://bugs.eclipse.org/bugs/show_bug.cgi?id=321390
>> So we went back and change JDK6 Updates back the way it was, and  
>> learned a valuable lesson.
>>
>> But we have and will change JDK7 in this regard, so we wanted a  
>> better way for an app to
>> know what it had it's hands on without using platform specific  
>> information in the binary files.
>>
>> The above change creates a small text file called "jdk.release" at  
>> the top of the install image
>> with some basic values that could help direct any app using the jdk  
>> in constructing a command
>> line or even being assured that this jdk install image will even  
>> work on your existing system.
>> In the Eclipse case it was looking for "Sun", but I suspect it  
>> really wanted to know if the VM was
>> "Hotspot" because I think it was trying to set a Hotspot specific  
>> PermGen option.
>> In any case I think this jdk.release file should provide the  
>> necessary answers in the future.
>>
>> The make variable COMPANY_NAME determines the vendor name during a  
>> build,
>> so a Linux 64bit build from a make command line like:
>>   make COMPANY_NAME="Test Company Name"
>> should result in a jdk.release file that looks something like:
>>
>> os.name = Linux
>> os.version = 2.6
>> os.arch = amd64
>> java.vendor = Test Company Name
>> java.version = 1.7.0-internal
>> java.vm.vendor = Test Company Name
>> java.vm.name = Hotspot(TM)
>> java.vm.version = 20.0-b02
>>
>> A formal Oracle jdk7 EA build on Linux 64bit should look something  
>> like:
>>
>> os.name = Linux
>> os.version = 2.6
>> os.arch = amd64
>> java.vendor = Oracle Corporation
>> java.version = 1.7.0-ea
>> java.vm.vendor = Oracle Corporation
>> java.vm.name = Hotspot(TM)
>> java.vm.version = 20.0-b02
>>
>> Comments are welcome. Although, polite constructive comments are  
>> probably more what I'd like to see. ;^)
>>
>> -kto
>>
>
> Kelly,
>
> Having been on the other side of the fence writing JVM independent
> launchers and startup scripts, I can attest to the value of having a
> standardized method of identifying a given JDK/JRE, so I don't want to
> be negative and discourage you from pushing OpenJDK forward.
> Unfortunately, if the intention is to truly allow identification of
> any JDK/JRE and its underlying JVM so that the proper JVM specific
> launcher arguments can be set, I'd think this file would need to
> become part of the Java SE specification so that all vendors conform
> to the same well-known file location, file format, and minimum
> property set (similar to the minimum runtime system property set
> defined by java.lang.System.getProperties() [1] [2]), or by
> standardizing the output of the recently added -XshowSettings flag [3]
> [4]. Are there any plans to include such standardizations in JSR 336
> for Java SE 7?

I had not even considered it. I assumed this would be an optional file  
that if
it existed, would have some minimal information to help direct the  
tools.
The identification of the JVM was very loose, essentially I just  
wanted to be
able to identify the implementation, and in general, given multiple VM's
it would be difficult to identify in a static way what VM you would  
get at
runtime.

>
> The most valuable property that Eclipse and others are looking for is
> java.vm.name, and this isn't a static compile time constant property
> causing this catch-22. Instead it is dependent on the underlying
> runtime JVM (e.g. server, client, jrockit, etc.) which in turn is
> determined by the launcher arguments. Hardcoding java.vm.name to
> "HotSpot(TM)" seems a little dirty and inconsistent to me. The vendor
> specific jvm.cfg defines the available JVMs for a given architecture,
> but even that file states that the file and format are unsupported and
> will go away in the future. I'm also curious how the java.vm.name
> value will change as more of JRockit is incorporated into OpenJDK.

Understood. Mark has pointed out another idea, I'll revise my webrev and
provide more details.

> Other properties such as os.* are also runtime system specific rather
> than static compile time properties so these could be misinterpreted.

The os.name is static in the way I have defined it, it's not a  
specific OS as
much as a OS family name. The os.version is meant as a minimum number
so that you could potentially avoid running jdk7 on a Windows 2000  
system.
The os.arch was meant as a minimal arch, if set to x64 it would imply  
that there
are no 32bit x86 binaries in this install image.
I had hoped to make some of these identical to the runtime Java  
properties, but
I'm becoming convinced that they are different, and maybe my names  
should also be
different, like minimum.os.name etc.

>
> I'm assuming the format of the file would be the typical
> java.util.Properties format, so I'd prefer naming the file
> jdk.properties or something to that effect. I'm also including a few

I am very reluctant to call this a properties file in that it won't be  
read in at startup
and it's values have no impact on the java install.

> snippets below of java.lang.System.getProperties() from various
> environments that seemed potentially interesting for use in a
> cross-platform JVM launcher. One interesting difference is that
> OpenJDK does not include "HotSpot(TM)" in the java.vm.name string. Is
> this due to trademark restrictions for OpenJDK?

I really appreciate this data, thank you, very helpful.

>
> Fortunately, the removal of Perm Gen in HotSpot improves the situation
> as it is one less critical non-standard VM argument to specify!

Yeah, oh well. I'm sure some other VM specific options will be needed  
someday. ;^)

-kto

>
> - Dave
>
> References:
> [1] http://download.oracle.com/javase/6/docs/api/java/lang/System.html#getProperties()
> [2] http://download.oracle.com/docs/cd/E15289_01/doc.40/e15062/sysprop.htm#i999740
> [3] http://markmail.org/message/mqluo6kj3d2haizg
> [4] http://hg.openjdk.java.net/jdk7/tl-gate/jdk/rev/32f3094b2c73
>
>
> ** OpenJDK 7 jdk7/jdk7 from November 29, 2010 on Ubuntu 10.04 Linux  
> x86 **
> java.runtime.name = OpenJDK Runtime Environment
> java.runtime.version = 1.7.0-internal-david_2010_11_29_22_09-b00
> java.specification.name = Java Platform API Specification
> java.specification.vendor = Sun Microsystems Inc.
> java.specification.version = 1.7
> java.vendor = Sun Microsystems Inc.
> java.vendor.url = http://java.sun.com/
> java.vendor.url.bug = http://java.sun.com/cgi-bin/bugreport.cgi
> java.version = 1.7.0-internal
> java.vm.info = mixed mode
> java.vm.name = OpenJDK Server VM
> java.vm.specification.name = Java Virtual Machine Specification
> java.vm.specification.vendor = Sun Microsystems Inc.
> java.vm.specification.version = 1.0
> java.vm.vendor = Sun Microsystems Inc.
> java.vm.version = 20.0-b03
> os.arch = i386
> os.name = Linux
> os.version = 2.6.32-23-generic
>
> ** OpenJDK 7 bsd-port from November 13, 2010 on Mac OS X 10.6.5 **
> java.runtime.name = OpenJDK Runtime Environment
> java.runtime.version = 1.7.0-internal-david_2010_11_16_20_46-b00
> java.specification.name = Java Platform API Specification
> java.specification.vendor = Oracle Corporation
> java.specification.version = 1.7
> java.vendor = Oracle Corporation
> java.vendor.url = http://java.oracle.com/
> java.vendor.url.bug = http://java.sun.com/cgi-bin/bugreport.cgi
> java.version = 1.7.0-internal
> java.vm.info = mixed mode
> java.vm.name = OpenJDK 64-Bit Server VM
> java.vm.specification.name = Java Virtual Machine Specification
> java.vm.specification.vendor = Oracle Corporation
> java.vm.specification.version = 1.0
> java.vm.vendor = Oracle Corporation
> java.vm.version = 20.0-b02
> os.arch = amd64
> os.name = Darwin
> os.version = 10.5.0
>
> ** Apple JDK 1.6.0_22 on Mac OS X 10.6.5 **
> java.runtime.name = Java(TM) SE Runtime Environment
> java.runtime.version = 1.6.0_22-b04-307-10M3261
> java.specification.name = Java Platform API Specification
> java.specification.vendor = Sun Microsystems Inc.
> java.specification.version = 1.6
> java.vendor = Apple Inc.
> java.vendor.url = http://www.apple.com/
> java.vendor.url.bug = http://bugreport.apple.com/
> java.version = 1.6.0_22
> java.vm.info = mixed mode
> java.vm.name = Java HotSpot(TM) 64-Bit Server VM
> java.vm.specification.name = Java Virtual Machine Specification
> java.vm.specification.vendor = Sun Microsystems Inc.
> java.vm.specification.version = 1.0
> java.vm.vendor = Apple Inc.
> java.vm.version = 17.1-b03-307
> os.arch = x86_64
> os.name = Mac OS X
> os.version = 10.6.5
>
> ** Oracle JDK 1.6.0_22 on Windows XP SP3 **
> java.runtime.name = Java(TM) SE Runtime Environment
> java.runtime.version = 1.6.0_22-b04
> java.specification.name = Java Platform API Specification
> java.specification.vendor = Sun Microsystems Inc.
> java.specification.version = 1.6
> java.vendor = Sun Microsystems Inc.
> java.vendor.url = http://java.sun.com/
> java.vendor.url.bug = http://java.sun.com/cgi-bin/bugreport.cgi
> java.version = 1.6.0_22
> java.vm.info = mixed mode, sharing
> java.vm.name = Java HotSpot(TM) Client VM
> java.vm.specification.name = Java Virtual Machine Specification
> java.vm.specification.vendor = Sun Microsystems Inc.
> java.vm.specification.version = 1.0
> java.vm.vendor = Sun Microsystems Inc.
> java.vm.version = 17.1-b03
> os.arch = x86
> os.name = Windows XP
> os.version = 5.1
>
> ** Sun/Oracle JDK 1.6.0_20 on Solaris 10 **
> java.runtime.name = Java(TM) SE Runtime Environment
> java.runtime.version = 1.6.0_20-b02
> java.specification.name = Java Platform API Specification
> java.specification.vendor = Sun Microsystems Inc.
> java.specification.version = 1.6
> java.vendor = Sun Microsystems Inc.
> java.vendor.url = http://java.sun.com/
> java.vendor.url.bug = http://java.sun.com/cgi-bin/bugreport.cgi
> java.version = 1.6.0_20
> java.vm.info = mixed mode
> java.vm.name = Java HotSpot(TM) Server VM
> java.vm.specification.name = Java Virtual Machine Specification
> java.vm.specification.vendor = Sun Microsystems Inc.
> java.vm.specification.version = 1.0
> java.vm.vendor = Sun Microsystems Inc.
> java.vm.version = 16.3-b01
> os.arch = sparc
> os.name = SunOS
> os.version = 5.10
>
> ** BEA JRockit 1.6.0_14 R27.6.5 on Windows XP SP3 **
> java.runtime.name = Java(TM) SE Runtime Environment
> java.runtime.version = 1.6.0_14-b08
> java.specification.name = Java Platform API Specification
> java.specification.vendor = Sun Microsystems Inc.
> java.specification.version = 1.6
> java.vendor = BEA Systems, Inc.
> java.vendor.url = http://www.bea.com/
> java.vendor.url.bug = http://edocs.bea.com/jrockit/go2troubleshooting.html
> java.version = 1.6.0_14
> java.vm.info = compiled mode
> java.vm.name = BEA JRockit(R)
> java.vm.specification.name = Java Virtual Machine Specification
> java.vm.specification.vendor = Sun Microsystems Inc.
> java.vm.specification.version = 1.0
> java.vm.vendor = BEA Systems, Inc.
> java.vm.vendor.url = http://www.bea.com/
> java.vm.vendor.url.bug = http://edocs.bea.com/jrockit/go2troubleshooting.html
> java.vm.version = R27.6.5-32_o-121899-1.6.0_14-20091001-2107-windows- 
> ia32
> os.arch = x86
> os.name = Windows XP
> os.version = 5.1
>
> ** Oracle JRockit 1.6.0_20 R28.0.1 on Windows XP SP3 **
> java.runtime.name = Java(TM) SE Runtime Environment
> java.runtime.version = 1.6.0_20-b02
> java.specification.name = Java Platform API Specification
> java.specification.vendor = Sun Microsystems Inc.
> java.specification.version = 1.6
> java.vendor = Oracle Corporation
> java.vendor.url = http://www.oracle.com/
> java.vendor.url.bug =
> http://download.oracle.com/docs/cd/E15289_01/go2troubleshooting.html
> java.version = 1.6.0_20
> java.vm.info = compiled mode
> java.vm.name = Oracle JRockit(R)
> java.vm.specification.name = Java Virtual Machine Specification
> java.vm.specification.vendor = Sun Microsystems Inc.
> java.vm.specification.version = 1.0
> java.vm.vendor = Oracle Corporation
> java.vm.vendor.url = http://www.oracle.com/
> java.vm.vendor.url.bug =
> http://download.oracle.com/docs/cd/E15289_01/go2troubleshooting.html
> java.vm.version = R28.0.1-21-133393-1.6.0_20-20100512-2132-windows- 
> ia32
> os.arch = x86
> os.name = Windows XP
> os.version = 5.1
>
> ** IBM J9 1.6.0 SR7 on AIX 6.1 **
> java.runtime.name = Java(TM) SE Runtime Environment
> java.runtime.version = pap6460sr7-20091215_02 (SR7)
> java.specification.name = Java Platform API Specification
> java.specification.vendor = Sun Microsystems Inc.
> java.specification.version = 1.6
> java.vendor = IBM Corporation
> java.vendor.url = http://www.ibm.com/
> java.version = 1.6.0
> java.vm.info = JRE 1.6.0 IBM J9 2.4 AIX ppc64-64
> jvmap6460sr7-20091214_49398 (JIT enabled, AOT enabled)\
>     J9VM - 20091214_049398\
>     JIT  - r9_20091123_13891\
>     GC   - 20091111_AA
> java.vm.name = IBM J9 VM
> java.vm.specification.name = Java Virtual Machine Specification
> java.vm.specification.vendor = Sun Microsystems Inc.
> java.vm.specification.version = 1.0
> java.vm.vendor = IBM Corporation
> java.vm.version = 2.4
> os.arch = ppc64
> os.name = AIX
> os.version = 6.1

More information about the build-dev mailing list