JDK-8197927 : Allow the system property `java.vendor.version` to be undefined
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.lang
  • Affected Version: 10
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2018-02-14
  • Updated: 2020-03-31
  • Resolved: 2019-06-06
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 13 JDK 14
13 b25Fixed 14Fixed
Related Reports
CSR :  
JDK-8225381 - Allow the system property `java.vendor.version` to be undefined
Relates :  
JDK-8241947 - Minor comment fixes for system property handling
Relates :  
JDK-8216383 - Remove the system property "java.vendor.version"
Description
The new Java 10 specification makes the 'java.vendor.version' property mandatory (http://cr.openjdk.java.net/~iris/se/10/pfd/java-se-10-pfd-spec/apidiffs/java/lang/System-report.html#method:getProperties()) 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).
Comments
[~mr] Thank you. The query is if "java.compiler" is not listed then it should not be mentioned in java doc of getProperties() ? filed JDK-8225772 a clarification request
14-06-2019
[~kganapureddy] I don���t know what ���supported��� means in this context. All of the properties listed in the specification of the `getProperties` method are specified. All of them are guaranteed to have a value except for `java.vendor.version`, which might have a value or might not, depending upon how the build was configured. `java.compiler` is not listed because it���s not a standard system property. If you think that���s a problem then please file a separate issue.
13-06-2019
[~mr] Just a clarification, As i understand all the property keys mentioned in (https://download.java.net/java/early_access/jdk13/docs/api/java.base/java/lang/System.html#getProperties()) are supported except the "java.vendor.version" Observed that "java.compiler" is also not listed in the getProperties() list?
13-06-2019
I think a better fix is to revise the specification to allow specific system properties to be undefined, as I've outlined in the CSR (JDK-8225381). I've changed the title of this issue to match.
05-06-2019
At this point there are known uses of this property, as documented in JDK-8216383, so this issue still needs to be resolved.
05-06-2019
At this point there is no known use of this property, so we should remove it as proposed in JDK-8216383.
08-01-2019
Dropping this non-current bug from JDK 11 and re-targeting to JDK 12, per JEP 3.
09-08-2018
This will be fixed by a specification change in Java 11 as proposed before and described on the mailing list: http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-February/051555.html Set priority to P2 and re-targeted to 11. Also assigned to Mark as requested by him. Not sure how to handle the jdk10-fix-request label tough which shouldn't be removed according to the JDK 10 Fix-Request process.
19-02-2018
I'm not comfortable with the fact that everybody will be forced to set 'java.vendor.version' to a non-empty value just because we don't want to fix this tiny bug. I'm also not comfortable with the fact that Java 10 introduces a new standard property just for removing it again in Java 11. I think there's still enough time to fix this trivial issue either way and I don't understand why there's such a resistance of doing it.
16-02-2018
The suggestion in earlier comments is to change the specification for Java SE 11 as it's not a blocking issue for 10.
16-02-2018
Because nobody agreed to change the API spec. If we re-target this to JDK 11 we will have to open another P1 for changing the API doc of java.lang.System.getProperties() and remove 'java.vendor.version' as a mandatory property from there. That new issue would also require a corresponding CSR request and obviously also a jdk10-fix-request. Either way is fine for me. Please let me know which one you prefer.
16-02-2018
Why has jdk10-fix-request been added to this issue? It's not critical for JDK 10 and I thought was going to be re-targeted to JDK 11 as a P2 spec change.
16-02-2018
WEBREV: http://cr.openjdk.java.net/~simonis/webrevs/2018/8197927/ RFR: http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-February/051431.html
16-02-2018
So what's your take on this? Should we change the API specification and remove the 'java.vendor.version' property from the set of required properties or should we set the property to the empty string if it was not specified at build time. I just saw that the corresponding JCK 10 test "tests/api/java_lang/System/GetPropertiesTests.java" doesn't check for the newly introduced properties anyway (which is bad!) but it helps here because we could just remove 'java.vendor.version' from the JavaDoc/API specification without the need to update the TCK.
15-02-2018
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. 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. How do I trigger a change Spec change for 10? Do I have to open a JBS bug for it or should I just write to java-se-spec-experts@openjdk.java.net?
14-02-2018
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 specification is not critical for 10; I suggest downgrading this to P2 and targeting 11.
14-02-2018
And by the way, I don't see any reason why Oracle is building its Early Access releases with java.vendor.version=18.3 That's at least confusing. What will you use for Java 11, 12, ... ? I thought we've definitely decided against calendar versioning, so why carrying it on in the vendor version property?
14-02-2018
Yes, but it is not possible to set it to an empty string and I don't see why we should enforce a non-empty vendor version. JEP 322 (http://openjdk.java.net/jeps/322) clearly indicated that it doesn't have to be set at build time and that it is empty in that case: ".. If not assigned at build time then it has no value.."
14-02-2018
As noted, specifying `configure --with-vendor-versin` ensures that the java.vendor.version is set. This means this issue has a workaround and doesn't really need to be a P1.
14-02-2018