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

[Kelly O'Hair]

On Nov 30, 2010, at 6:10 AM, Dr Andrew John Hughes wrote:

> On 14:44 Mon 29 Nov     , Kelly O'Hair 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
>>
>
> So what happens if a build does not set COMPANY_NAME?  There won't
> always be an appropriate value for this.

I think the default for OpenJDK builds is "N/A".

But mark at klomp.org is beginning to convince me that the vendor names  
should be left out.

>
> Given this is aimed mainly at the Eclipse hackers, have they been
> notified of this addition?

Yes. https://bugs.eclipse.org/bugs/show_bug.cgi?id=321390

>
> I agree with the previous comment that it should use the standard
> '.properties' extension and be standardised for cross-JDK usage.  Of
> course, that's only useful if the JSR concerned is actually available
> under terms which will allow their use with FOSS.  I believe this is
> still not the case with most JSRs.

But they aren't really properties and I didn't want them to be  
confused with the real runtime property values.
In fact I'm beginning to think I should use names that do NOT match  
any Java property names.
The property name=value syntax was just handy and could be useful for  
tools.

-kto

>
> -- 
> Andrew :)
>
> Free Java Software Engineer
> Red Hat, Inc. (http://www.redhat.com)
>
> Support Free Java!
> Contribute to GNU Classpath and the OpenJDK
> http://www.gnu.org/software/classpath
> http://openjdk.java.net
> PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
> Fingerprint = F8EF F1EA 401E 2E60 15FA  7927 142C 2591 94EF D9D8