`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 <pbened...@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.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 > > > >
