Why is java -version implemented in Java?

[Thomas Stüfe]

Thanks Michael, that's an important point.

So when I half-jokingly wrote that "-version" is used as a cheap first-line
VM test I was not wrong, and not only OpenJDK developers do that. People
seem to rely on "-version" parsing arguments and initializing the JVM.
Which also would prevent us from modifying command line options to save
initialization time, e.g. adding -Xint.

Pity. I guess we could run JVM initialization and still cut out the actual
invocation of VersionProps.java and just print all those infos from native
code within the hotspot. But I'm not sure how much this would actually save.

Cheers, Thomas


On Fri, Nov 20, 2020 at 11:50 PM Michael Bien <mbien42 at gmail.com> wrote:

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