RFE to re-purpose option --version:<version>

Paul Benedict pbenedict at apache.org
Wed Aug 10 17:34:27 UTC 2016

Many, thanks again for following up. Unfortunately, the "release" file is
not available in my operating environment. The installed JDK/JRE images on
my servers have been slimmed down by system administrators. I suppose my
recourse will simply have to be executing Java twice -- once for the
version check (piping, parsing, etc.) and another if the check succeeds. I
wanted to avoid this situation but I don't see another avenue as of today.
Anecdotally, sometimes there is a delay in spinning up Java the first time,
but it doesn't always happen, and I also don't understand why (especially
since it's just to spit out the version).

When Claes opined earlier, he considered my proposal a "niche use case" but
I don't share that opinion. In my experience with Java on the server-side,
I find three perspectives on booting applications:
(1) Just assume the right Java version (runtime exceptions will let you
know otherwise)
(2) Check the Java version first via shell scripting
(3) Check the Java version first in application main()

My proposal aims to make case #1 inexcusable, improve the usability of case
#2, and eliminate the need for case #3. In my world, servers usually have
multiple versions of Java installed. Some applications can run without
error on multiple Java versions, but policy dictates just one (for such
reasons like QA and/or maintaining vendor support). So I don't consider
this proposal to be all that niche. It really comes down to verifying the
platform major version (and possibly minor version) before going any


On Tue, Aug 9, 2016 at 12:30 PM, Mandy Chung <mandy.chung at oracle.com> wrote:

> If you are only looking for the version, would JAVA_VERSION satisfy your
> need? JAVA_FULL_VERSION is only present in JDK and JRE image but not custom
> image since the property is supplied by the jdk build.
> Mandy
> > On Aug 9, 2016, at 9:49 AM, Paul Benedict <pbenedict at apache.org> wrote:
> >
> > No, I haven't considered that. Thank you, Mandy. Good tip. And I see
> that file also contains JAVA_FULL_VERSION, whose value is identical to the
> -fullversion option output.
> >
> > Cheers,
> > Paul
> >
> > On Tue, Aug 9, 2016 at 11:40 AM, Mandy Chung <mandy.chung at oracle.com>
> wrote:
> >
> > > On Aug 8, 2016, at 8:51 AM, Paul Benedict <pbenedict at apache.org>
> wrote:
> > >
> > > However, I would like to propose bringing back the option with a
> different
> > > purpose. I would like to use --version:<version> as a validation
> check. I
> > > want Java to execute ONLY if the version specified matches the actual
> > > platform version. This would be a wonderful help to scripts that
> require a
> > > particular version of the Java platform, and should fail if the
> environment
> > > has been accidentally setup with the wrong Java platform version.
> > >
> > > Examples:
> > > java --version:9
> > > java --version:9.1
> > >
> > > AFAICT, the only way to do this now is to execute Java twice. Once to
> pipe
> > > --version to some find/grep command and check return code, and then
> execute
> > > java again if the check pass. Loading the runtime twice is not optimal,
> > > wouldn't you agree? Yet if you agree to this proposal, it would be a
> big
> > > win for script writers, I believe.
> >
> > Have you considered checking the JAVA_VERSION property in
> $JAVA_HOME/release file?  jlink creates the `release` file containing
> certain properties about the runtime image.
> >
> > Mandy
> >

More information about the core-libs-dev mailing list