Why is java -version implemented in Java?

Thomas Stüfe thomas.stuefe at gmail.com
Fri Nov 20 19:44:50 UTC 2020

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

Cheers, Thomas

More information about the jdk-dev mailing list