Like the already supported "os.name" system property, "os.version" is often used in informational and diagnostic messages, which makes it worthwhile to support.
@fcurts I will add support for the os.version system property.
@olpaw @cstancu is it a high priority target? I could try to implement this.
Important question on this topic. What's the policy of reusing code from main OpenJDK? I mean, we already have a code for os.version (and many other interesting things), maybe we should just migrate it (with reasonable refactorings)?
Fixed by #568
The most straightforward solution, because os.version is quite fast.
Should we make it lazier?
Reusing OpenJDK code, i.e., copying and pasting it, is ok from a licensing standpoint, however we must have a good reason to do so. If a feature can be implemented by reusing the JDK code without copying it, e.g., patching it through a substitution, then that is preferable.
By the way, @olpaw is already working on getting the right os.version at runtime.
@cstancu it's in final testing. It will land today (or tomorrow).
Fixed in 4529207aa55
This change adds system property support for:
os.version
java.version
java.vendor
java.vendor.url
Most helpful comment
@fcurts I will add support for the
os.versionsystem property.