Why is java -version implemented in Java?
mbien42 at gmail.com
Fri Nov 20 22:46:38 UTC 2020
On 20.11.20 20:44, Thomas Stüfe wrote:
> On Fri, Nov 20, 2020 at 7:39 PM Volker Simonis <volker.simonis at gmail.com>
>> On Fri, Nov 20, 2020 at 7:08 PM Alan Bateman <Alan.Bateman at oracle.com>
>>> On 20/11/2020 16:22, Thomas Stüfe wrote:
>>>> java -version seems to be called by scripts very frequently to get the
>>>> version. Folks complain about the time that takes.
>>>> I always wondered, why is this implemented in java? Which requires the
>>>> whole jvm machinery to start up just to print the version information.
>>>> VersionProps.java seems not to be very complex; that information could
>>>> been baked into the launcher, or the hotspot.
>>>> Or is using 'java -version' as a simple VM test just too convenient?
>>> The alternative to scripts running `java -version` is to examine the
>>> `release` file in the top-level directory. Could the scripts that you've
>>> encountered be changed to look at that instead?
>> That's an alternative but not the answer to the question :)
> Yes, I was hoping for some background information about why we do it
> this way.
> I know about the "release" file, but this does not seem like an obvious
> solution. I see this file mentioned as a way to quickly get the java
> release info, but it seems so strange and non-obvious. I feel bad that
> users have to even do that.
> Also, to me, that file does not seem to correspond clearly with the
> -version information.
>> I'm also not sure how "common" or "standard the "release" file is? I
>> know at least two popular distributions which don't have that file
>> while "-version" seems to be a documented and supported option.
>> I think there's probably a lot of history and legacy around "-version"
>> and it's implementation. It actually prints "many" versions, e.g. the
>> VM version, the class library version, etc. Most of the "-version"
>> output is also exported as system properties and as such only
>> "generated" at runtime.
>> Maybe one solution could be to implement a short-cut into OpenJDK's
>> standard launcher to use the information from the "release" file if
>> that is present? That should be pretty safe as the times when you
>> could simple swap the VM in a JDK release are long gone :)
> An even simpler way could be just to bake the release information as
> strings into the java launcher and print those. No need to even open and
> parse that file. j.l.VersionProps.java gets generated from a template, a
> C-file with strings could be generated the same way.
> But I am sure it's not that easy and I overlook something. Hence my
java -version does more than just printing static version Strings. It
prints if class data sharing is active and which mode the JIT is in
(mixed mode by default).
openjdk version "15.0.1" 2020-10-20
OpenJDK Runtime Environment (build 15.0.1+9-18)
OpenJDK 64-Bit Server VM (build 15.0.1+9-18, mixed mode, sharing)
I am (ab)using it sometimes to test JDK features when i forget which
distribution has what enabled.
java -Xshare:on -version
is going to fail if CDS is not properly set up.
java -XX:+UseShenandoahGC -version
is going to fail if its an Oracle JDK
I just wanted to mention this because i might not be the only one using
-version as --dry-run equivalent.
> Cheers, Thomas
More information about the jdk-dev