[1] RFR(XXS): 8197927: Can't set mandatory 'java.vendor.version' property to empty string

Volker Simonis volker.simonis at gmail.com
Wed Feb 14 11:03:04 UTC 2018


Thanks Thomas.

The sole reason for making it P1 is that it is currently not possible
to build a Java 10 conforming version of OpenJDK with an empty vendor
version.

The specification doesn't mandate a non-empty vendor version and I
don't think OpenJDK should mandate on either.

Regards,
Volker

On Wed, Feb 14, 2018 at 11:50 AM, Thomas Stüfe <thomas.stuefe at gmail.com> wrote:
> Fix is fine, trivial and I do not think there is any risk attached to it. I
> am not in any position to comment whether this is P1. Copyright year needs
> adjusting.
>
> Kind Regards, Thomas
>
> On Wed, Feb 14, 2018 at 11:20 AM, Volker Simonis <volker.simonis at gmail.com>
> wrote:
>>
>> Hi,
>>
>> can I please get a review for the following tiny fix:
>>
>> http://cr.openjdk.java.net/~simonis/webrevs/2018/8197927/
>> https://bugs.openjdk.java.net/browse/JDK-8197927
>>
>> The new Java 10 specification makes the 'java.vendor.version' property
>> mandatory [1] but the current implementations doesn't allow to set it
>> to an empty string.
>>
>> Currently, if we don't configure the build with
>> --with-vendor-version=XXX the 'java.vendor.version' property won't be
>> set at all, which violates the spec. Setting it to an empty string
>> will be ignored and has the same behavior like not setting it at all.
>> This also makes default OpenJDK builds (which haven't been configured
>> with --with-vendor-version non-compliant).
>>
>> The fix is trivial: unconditionally set the 'java.vendor.version'
>> property to the value of VENDOR_VERSION_STRING in
>> VersionProps.java.template, even if VENDOR_VERSION_STRING is the empty
>> string (which is the default if --with-vendor-version wasn't given at
>> config time).
>>
>> Thank you and best regards,
>> Volker
>>
>>
>> [1]
>> http://cr.openjdk.java.net/~iris/se/10/pfd/java-se-10-pfd-spec/apidiffs/java/lang/System-report.html#method:getProperties()
>
>


More information about the core-libs-dev mailing list