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