Why is java -version implemented in Java?

[Michael Bien]

'java --dry-run' will currently print the help (and exit with 1) if no 
jar/mainclass/etc has been provided. Maybe this could be omitted to make 
it script friendlier. That might be the reason why i have seen 'java 
-Xshare:on -version' in scripts before, instead of 'java -Xshare:on 
--dry-run' which is more descriptive.

i don't think -v is taken yet. This might be the way out to add a fast 
path, while -version (and --version) would remain unchanged for printing 
instance specific settings (sharing, mixed mode, etc) additionally to 
the version.

(just an idea)

best regards,
michael

On 22.11.20 06:57, Thomas Stüfe wrote:
> 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 
> <mailto: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 <mailto:volker.simonis at gmail.com>>
>     > wrote:
>     >
>     >> On Fri, Nov 20, 2020 at 7:08 PM Alan Bateman
>     <Alan.Bateman at oracle.com <mailto: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
>
>