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.ch...@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 <pbened...@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.ch...@oracle.com> > wrote: > > > > > On Aug 8, 2016, at 8:51 AM, Paul Benedict <pbened...@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 > > > >
