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

mark.reinhold at oracle.com mark.reinhold at oracle.com
Fri Feb 16 18:02:02 UTC 2018

2018/2/14 8:04:15 -0800, volker.simonis at gmail.com:
> On Wed, Feb 14, 2018 at 4:26 PM, mark.reinhold at oracle.com wrote:
>> This is a bug in the specification, not the implementation.  As I just
>> wrote in a comment on 8197927:
>> JEP 322 expresses the intended behavior: If `--with-vendor-version` is
>> not specified at build time then the `java.vendor.version` property has
>> no value.  (That's different from the empty string, which is a value.)
>> The bug is in the specification, which should be revised so as not to
>> require that this property have a value.  Fixing the spec is not
>> critical for 10; I suggest downgrading 8197927 to P2 and targeting 11.
> What you mean by "not require the 'java.vendor.version' property to
> have a value"? We can not set a system property to NULL because
> System.setProperty() will throw a NPE in that case. So either the
> specification requires 'java.vendor.version' as mandatory (as it is
> now) in which case it does need to have a value different from NULL.
> Or we change the specification such that 'java.vendor.version' isn't a
> mandatory property any more. But it is not possible to have
> 'java.vendor.version' as mandatory property with "no value" as
> envisioned by the JEP.

Of course it's possible.  The specification need merely say that
`java.vendor.version` is a standard system property that may, or may
not, have a value.  (Or, if you like, whose value may be `null`.)

> Do you propose to change the specification such that
> 'java.vendor.version' isn't a mandatory property any more? That would
> be fine for me and I agree that we could target this bug to 11 if
> that's what you propose. We could actually list "java.vendor.version"
> under "Implementation Note:" which contains some additional,
> non-mandatory properties.

It'd be a standard property, not an implementation-specific property.

Feel free to reassign 8197927 to me and I'll fix it in 11, since it was
my oversight in the first place.

- Mark

More information about the core-libs-dev mailing list