Why is java -version implemented in Java?
Magnus Ihse Bursie
magnus.ihse.bursie at oracle.com
Mon Nov 23 12:52:58 UTC 2020
On 2020-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
Just to clarify: that would not be hard to do.
From a build point of view, there is much to be done about how versions
are handled. The default behavior unfortunately is to create "ad hoc"
version strings for developer builds, which needs to be updated in
source code, causing build changes to propagate throughout the chain for
even the simplest changes.
I think a much better solution would be to not hard-code version
information in any native binary, shared library or class file, but
instead read it from a text file. If the release file does not match
what java -version prints, then perhaps an additional line (or lines)
should be added to the release file, with this content. That would also
allow tooling to read the file and get the *exact* same output as java
-version should have provided.
And, of course, a change in version string would not require a full rebuild.
With that said, I think the sad fact, as you've seem to have concluded,
is that people are expecting java -version to start up a VM, and we
can't really do anything about that.
One thought I have, and I don't know if that is good or bad, is that the
new, GNU-style long-option java --version that was introduced not too
long ago is not as likely to have this legacy of expecting VM startup.
It might be possible to redefine it to just print the version to stdout
and just exit. But that also means that java -version and java --version
behaves differently, and I don't know if that really is a good idea.
> Cheers, Thomas
More information about the jdk-dev