Why is java -version implemented in Java?

[Magnus Ihse Bursie]

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

/Magnus
>
> Cheers, Thomas