Why is java -version implemented in Java?
mbien42 at gmail.com
Tue Nov 24 02:27:45 UTC 2020
'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
(just an idea)
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
> >>>> 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
> >>> 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
> > 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
> >> 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
> -version as --dry-run equivalent.
> best regards,
> > Cheers, Thomas
More information about the jdk-dev