On Thu, 11 Jan 2018 07:49:40 -0600, Matt Benson wrote:
On Jan 10, 2018 9:22 PM, "Gary Gregory" <garydgreg...@gmail.com>
wrote:
On Wed, Jan 10, 2018 at 5:44 PM, Matt Benson <mben...@apache.org>
wrote:
As I'm sure you're aware, the planned obsolescence of this approach
is its
obvious drawback (a similar drawback exists already in the
JavaVersion
parameter type). I assume this is the reason you said "technical
reasons."
However, wouldn't it be straight up simple, as well as future proof
(if
done correctly), to provide a method that tests an int against the
available major Java version?
Hi Matt,
What would that look like?
The usage would look like:
if (SystemUtils.isJavaMajorVersionAtLeast(8)) {
...
}
Or, as Gilles suggests, you could simply have
SystemUtils.getJavaVersion()
Actually, I suggest to define the functionality inside
"JavaVersion" (and to stop bloating "...Utils" classes
whenever a cleaner alternative can be considered).
Gilles
and have methods from there to test against another JavaVersion
instance.
The possibilities are wide open. For brevity, maybe do a number of
relational methods with short names eq|ne|lt|le|gt|ge and overload
like:
boolean gt(JavaVersion v);
boolean gt(int... v);
boolean ge(JavaVersion v);
boolean ge(int... v);
Permitting:
SystemUtils.getJavaVersion().ge(8);
SystemUtils.getJavaVersion().gt(8, 0);
etc.
Matt
Gary
Matt
On Jan 10, 2018 6:35 PM, "Gary Gregory" <garydgreg...@gmail.com>
wrote:
Hi All:
I find myself writing a lot of this kind of code:
if (SystemUtils.isJavaVersionAtLeast(JavaVersion.JAVA_1_8)) ...
and
Assume.assumeTrue(SystemUtils.isJavaVersionAtLeast(JavaVersion.JAVA_1_8));
I think this would be more tidy:
if (SystemUtils.isJavaVersionAtLeast8()) ...
If this makes your skin crawl, please present a (technical) argument
against it...
Gary
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
