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()
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
>
