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

[Mandy Chung]

`release` contains the version info you need and the file is very small that I don’t see any issue having it on a production system.  I think it doesn’t worth the effort to add —-version:9 in the launcher.

Mandy

> On Aug 10, 2016, at 10:34 AM, Paul Benedict <pbenedict at apache.org> wrote:
> 
> 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 further.
> 
> Cheers,
> Paul
> 
> 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
> >
> 
>