OpenJDK/IcedTea naming patch

Mark Reinhold mr at sun.com
Mon Feb 23 14:45:21 PST 2009


> Date: Mon, 23 Feb 2009 22:12:51 +0000
> From: Andrew John Hughes <gnu_andrew at member.fsf.org>

> 2009/2/23 Mark Reinhold <mr at sun.com>:
>> Agree on the fairness angle, but I know a few HotSpot engineers who'd
>> argue with your parenthetical point.
>> 
> 
> Well I wasn't suggesting a VM as capable as HotSpot :)
> I was just pointing out that there were lots of Free VMs with varying
> goals and levels of completeness before HotSpot was made available
> under the GPL.  All of these were sufficient to run Java programs,
> even if not being on quite the same performance or feature level as
> HotSpot.  But there was no complete class library implementation, and
> the one in OpenJDK remains the only one now (mainly by virtue of being
> the reference implementation; it can set the bar rather than chasing
> it).

Understood -- I said that mainly for (lame) humor value.

>>> ...
>>> 
>>> I like this change, it seems to reach a happy medium.  I notice you
>>> also change the version template.  What is the value of the
>>> java.version property as a result?  The same as those listed above?
>> 
>> The value of java.version doesn't change; it's still set from
>> FULL_VERSION, as before, and the value of that make variable has
>> not changed.
> 
> Ok, then what does the version template change mean? :)

I added two fields, jdk_derivative_name and distro_package_version,
which are initialized at build time from the corresponding new make
variables.

I also rewrote the print(PrintStream) method to format the output
according to whether those fields have non-empty values.

The java.version system property is still set, in the static init()
method, to the value of the java_version field, which is still defined
at build time as the value of the RELEASE make variable, which hasn't
changed.  (I mis-wrote FULL_VERSION in my previous reply.)

- Mark



More information about the distro-pkg-dev mailing list