On 10/08/2016 23:46, Martin Buchholz wrote:
On Wed, Aug 10, 2016 at 11:52 AM, Paul Benedict
wrote:
Martin, what do you have in mind when saying it's "broken"? Functionally,
everything is fine -- I can delete "release" locally without issue (so it
appears) -- so I
On Wed, Aug 10, 2016 at 11:52 AM, Paul Benedict
wrote:
> Martin, what do you have in mind when saying it's "broken"? Functionally,
> everything is fine -- I can delete "release" locally without issue (so it
> appears) -- so I imagine there's humor here I am missing? :-)
>
Martin, what do you have in mind when saying it's "broken"? Functionally,
everything is fine -- I can delete "release" locally without issue (so it
appears) -- so I imagine there's humor here I am missing? :-)
Cheers,
Paul
On Wed, Aug 10, 2016 at 1:36 PM, Martin Buchholz
On Wed, Aug 10, 2016 at 10:34 AM, Paul Benedict
wrote:
> 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.
Your system administrators have
`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 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
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 wrote:
>
> No, I
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 wrote:
>
> > On Aug 8, 2016, at 8:51
> On Aug 8, 2016, at 8:51 AM, Paul Benedict wrote:
>
> However, I would like to propose bringing back the option with a different
> purpose. I would like to use --version: as a validation check. I
> want Java to execute ONLY if the version specified matches the actual
>
Opinions!
1. --version:9 is ambiguous, maybe --require-version=9 would be better...
2. ... but it still doesn't seem worth the hours of testing, maintenance
and subsequent bug-fixing for this niche use case
3. ... and even if it did get in there'd be a very long time until all
versions of java
Kumar, thank you for that information. I find that useful too. Now with
regard to this email's proposal, are there any further opinions? If this
has merit, I would appreciate if someone could create a ticket for
consideration?
Cheers,
Paul
On Mon, Aug 8, 2016 at 4:20 PM, Kumar Srinivasan <
Hello Paul,
There is a light weight method to get the version from the launcher,
"-fullversion" noting that, this does not invoke the VM, and obtains
the version string set at build time in the launcher itself.
However you would have to exec java twice, once to get the version,
another to
Dear Committers,
In Java 9, the --version: has been deprecated. The error message
returned to me is:
Error: Specifying an alternate JDK/JRE version is no longer supported.
The use of the flag '-version:' is no longer valid.
Please download and execute the appropriate version.
Unrecognized
13 matches
Mail list logo