Why is java -version implemented in Java?

[Michael Bien]

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>
> wrote:
>
>> On Fri, Nov 20, 2020 at 7:08 PM Alan Bateman <Alan.Bateman at oracle.com>
>> wrote:
>>> On 20/11/2020 16:22, Thomas Stüfe wrote:
>>>> Hi,
>>>>
>>>> java -version seems to be called by scripts very frequently to get the
>> java
>>>> 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
>> have
>>>> 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
> question.

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).

jdk-15.0.1_oracle/bin/java -version
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.

best regards,

michael


>
> Cheers, Thomas