You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Gilles Sadowski <gi...@gmail.com> on 2021/06/09 14:28:36 UTC

[Numbers][All] Separate Java target version for "src/test"

Hi.

"Commons Numbers" POM of module "commons-numbers-core"
contains
---CUT---
    <!-- JDK 9+ required for BigDecimal.sqrt() method in unit tests. -->
    <maven.compiler.testSource>1.9</maven.compiler.testSource>
    <maven.compiler.testTarget>1.9</maven.compiler.testTarget>
---CUT---

Running
$ JAVA_HOME=/usr/lib/jvm/java-8-openjdk-amd64/ mvn test site site:stage
fails:
---CUT---
[...]
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-compiler-plugin:3.8.1:testCompile
(default-testCompile) on project commons-numbers-core: Fatal error
compiling: invalid target release: 1.9 -> [Help 1]
---CUT---

Regards,
Gilles

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Re: [Numbers][All] Separate Java target version for "src/test"

Posted by Gilles Sadowski <gi...@gmail.com>.
Le mer. 9 juin 2021 à 20:58, Alex Herbert <al...@gmail.com> a écrit :
>
> On Wed, 9 Jun 2021 at 17:56, sebb <se...@gmail.com> wrote:
>
> > On Wed, 9 Jun 2021 at 17:26, Alex Herbert <al...@gmail.com>
> > wrote:
> > >
> > > On Wed, 9 Jun 2021 at 17:03, John Patrick <nh...@gmail.com>
> > wrote:
> > >
> > > > Have you tried "9" instead of "1.9"?
> > > >
> > >
> > > I've corrected that in the pom, thanks.
> > >
> > > I think the issue is that Gilles used JDK 8 to try and build it. You can
> > > run using the project's main artifacts using JDK 8, but the build now
> > > requires JDK 9 for the tests and JMH performance tests.
> >
> > That seems wrong. If the code targets Java 8, it must be possible to
> > test it using Java 8.
> >
> > It's possibly OK to require JDK 9 for performance tests.

IIRC, the explicit setting of "JAVA_HOME" was intended to ensure
that the binaries are created with the correct bytecode version.

So, indeed,
$ JAVA_HOME=/usr/lib/jvm/java-8-openjdk-amd64/ mvn test site site:stage
does not work with "9" either.

Should we just skip this "validation" test (and solely rely on the compiler
settings in the POM being correct)?


Gilles

>
> The test is using JDK 9 for the BigDecimal sqrt method. This is used to
> compute the exact answer for a Euclidean norm on random input. Since the
> input is random the answers cannot be hard-coded into the test. So this
> test is not possible on JDK 8. The alternative is if the exact computation
> is done using BigDecimal, converted to double, and then a sqrt computed. We
> could change to that instead if there are strong objections here against
> java 9.
>
> The issue with requiring a higher JDK than the target is similar to using
> JDK 8 so that JUnit 5 can be used for the test suite to test code that
> targets a level lower than 1.8.
>
> Alex

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Re: [EXTERNAL] Re: [Numbers][All] Separate Java target version for "src/test"

Posted by Gilles Sadowski <gi...@gmail.com>.
Hello.

Le lun. 14 juin 2021 à 00:37, John Patrick <nh...@gmail.com> a écrit :
>
> So I want to start using Java 11 and take advantage of Java Modules. But
> with a bug in Java Multi-Jar not supporting 1.8 as base and 11 upon that,
> and most dependencies I want to upgrade eventually get stuck on a commons
> project holding a pure JPMS solution.
>
> Potentially someone raise an enhancement to drop support for Java 1.8 which
> isn't happening for Java 17, but for Java 18 which is only 8 month away it
> could happen. So at that point it might be a shock for commons projects as
> you might be blocking open source projects, or they roll off commons
> projects... just a thought.
>
> I've tried to do a seamless upgrade, or suggest a roadmap, but haven't got
> anywhere, but think I might just raise a JEP to drop 1.8 in Java 18...

I'm not sure I don't understand what you mean.  If it's about the possiblity
to use JPMS: "Commons RNG" project has an example[1] showing that it
seems to work when the code is used within a Java 9+ environment, even
though the component itself is still targetted at Java 1.6.

Regards,
Gilles

[1] https://gitbox.apache.org/repos/asf?p=commons-rng.git;a=tree;f=commons-rng-examples/examples-jpms;h=64999d7bd370e374fbe801d8bc376ba17ea55970;hb=HEAD

>>> [...]

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Re: [EXTERNAL] [Numbers][All] Separate Java target version for "src/test"

Posted by Ralph Goers <ra...@dslextreme.com>.
I don’t understand this. Log4j2 was one of the first adopters of multi-release jars. 
There were problems in the beginning but those have virtually all been resolved. 
We haven’t had any complaints in ages. Log4j 2 2.14.1 supports Java 8. 

Fully supporting JPMS (i.e. - adding a module-info.java file) while trying to support 
Java 8 is another thing entirely. I gave up on that and the minimum JDK version 
for that will be Java 11.

Ralph

> On Jun 13, 2021, at 3:37 PM, John Patrick <nh...@gmail.com> wrote:
> 
> So I want to start using Java 11 and take advantage of Java Modules. But
> with a bug in Java Multi-Jar not supporting 1.8 as base and 11 upon that,
> and most dependencies I want to upgrade eventually get stuck on a commons
> project holding a pure JPMS solution.
> 
> Potentially someone raise an enhancement to drop support for Java 1.8 which
> isn't happening for Java 17, but for Java 18 which is only 8 month away it
> could happen. So at that point it might be a shock for commons projects as
> you might be blocking open source projects, or they roll off commons
> projects... just a thought.
> 
> I've tried to do a seamless upgrade, or suggest a roadmap, but haven't got
> anywhere, but think I might just raise a JEP to drop 1.8 in Java 18...
> 
> John
> 
> 
> On Thu, 10 Jun 2021 at 14:07, Gilles Sadowski <gi...@gmail.com> wrote:
> 
>> Le jeu. 10 juin 2021 à 14:42, John Patrick <nh...@gmail.com> a
>> écrit :
>>> 
>>> If the tests are valid and useful once post Java 1.8, what about
>>> starting the next release branch where the min version bumps to Java
>>> 11.
>> 
>> [Numbers] and related components were meant to replace and
>> improve some functionalities provided in [Math] v3.6.1 whose
>> target was Java 5 (!).
>> A few years ago, the bump to Java 8 was considered a bold move
>> (for "Commons"). :-}
>> 
>> If we are sure that Java 11 is no problem for anyone who'd go
>> through the upgrade effort, then indeed why not?
>> 
>> Gilles
>> 
>>> As Java 17 starting ramp down starts today I believe so in 3 months we
>>> will have 3 LTS (1.8, 11 and 17) releases. So technically Java 18
>>> development starts tomorrow and I expect 1.8 will be dropped shortly
>>> from backwards support as they want to get off the classpath fully and
>>> onto the modules path.
>>> 
>>> Anyway, just a thought.
>>> 
>>> John
>>> 
>>> On Thu, 10 Jun 2021 at 12:05, sebb <se...@gmail.com> wrote:
>>>> 
>>>> Thanks.
>>>> 
>>>> I've updated the RELEASE-NOTES accordingly (feel free to tweak the
>> text)
>>>> 
>>>> On Thu, 10 Jun 2021 at 00:58, Alex Herbert <al...@gmail.com>
>> wrote:
>>>>> 
>>>>> I have removed the requirement for Java 9 from the build. It is
>> still used
>>>>> in the performance testing module.
>>>>> 
>>>>> Alex
>> 
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>> 
>> 



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Re: [EXTERNAL] Re: [Numbers][All] Separate Java target version for "src/test"

Posted by sebb <se...@gmail.com>.
On Sun, 13 Jun 2021 at 23:37, John Patrick <nh...@gmail.com> wrote:
>
> So I want to start using Java 11 and take advantage of Java Modules. But
> with a bug in Java Multi-Jar not supporting 1.8 as base and 11 upon that,
> and most dependencies I want to upgrade eventually get stuck on a commons
> project holding a pure JPMS solution.
>
> Potentially someone raise an enhancement to drop support for Java 1.8 which
> isn't happening for Java 17, but for Java 18 which is only 8 month away it
> could happen. So at that point it might be a shock for commons projects as
> you might be blocking open source projects, or they roll off commons
> projects... just a thought.
>
> I've tried to do a seamless upgrade, or suggest a roadmap, but haven't got
> anywhere, but think I might just raise a JEP to drop 1.8 in Java 18...

So Java is no longer always upwards compatible?

I thought it was supposed to be "Write once, run anywhere". ?

> John
>
>
> On Thu, 10 Jun 2021 at 14:07, Gilles Sadowski <gi...@gmail.com> wrote:
>
> > Le jeu. 10 juin 2021 à 14:42, John Patrick <nh...@gmail.com> a
> > écrit :
> > >
> > > If the tests are valid and useful once post Java 1.8, what about
> > > starting the next release branch where the min version bumps to Java
> > > 11.
> >
> > [Numbers] and related components were meant to replace and
> > improve some functionalities provided in [Math] v3.6.1 whose
> > target was Java 5 (!).
> > A few years ago, the bump to Java 8 was considered a bold move
> > (for "Commons"). :-}
> >
> > If we are sure that Java 11 is no problem for anyone who'd go
> > through the upgrade effort, then indeed why not?
> >
> > Gilles
> >
> > > As Java 17 starting ramp down starts today I believe so in 3 months we
> > > will have 3 LTS (1.8, 11 and 17) releases. So technically Java 18
> > > development starts tomorrow and I expect 1.8 will be dropped shortly
> > > from backwards support as they want to get off the classpath fully and
> > > onto the modules path.
> > >
> > > Anyway, just a thought.
> > >
> > > John
> > >
> > > On Thu, 10 Jun 2021 at 12:05, sebb <se...@gmail.com> wrote:
> > > >
> > > > Thanks.
> > > >
> > > > I've updated the RELEASE-NOTES accordingly (feel free to tweak the
> > text)
> > > >
> > > > On Thu, 10 Jun 2021 at 00:58, Alex Herbert <al...@gmail.com>
> > wrote:
> > > > >
> > > > > I have removed the requirement for Java 9 from the build. It is
> > still used
> > > > > in the performance testing module.
> > > > >
> > > > > Alex
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
> >

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Re: [EXTERNAL] Re: [Numbers][All] Separate Java target version for "src/test"

Posted by John Patrick <nh...@gmail.com>.
So I want to start using Java 11 and take advantage of Java Modules. But
with a bug in Java Multi-Jar not supporting 1.8 as base and 11 upon that,
and most dependencies I want to upgrade eventually get stuck on a commons
project holding a pure JPMS solution.

Potentially someone raise an enhancement to drop support for Java 1.8 which
isn't happening for Java 17, but for Java 18 which is only 8 month away it
could happen. So at that point it might be a shock for commons projects as
you might be blocking open source projects, or they roll off commons
projects... just a thought.

I've tried to do a seamless upgrade, or suggest a roadmap, but haven't got
anywhere, but think I might just raise a JEP to drop 1.8 in Java 18...

John


On Thu, 10 Jun 2021 at 14:07, Gilles Sadowski <gi...@gmail.com> wrote:

> Le jeu. 10 juin 2021 à 14:42, John Patrick <nh...@gmail.com> a
> écrit :
> >
> > If the tests are valid and useful once post Java 1.8, what about
> > starting the next release branch where the min version bumps to Java
> > 11.
>
> [Numbers] and related components were meant to replace and
> improve some functionalities provided in [Math] v3.6.1 whose
> target was Java 5 (!).
> A few years ago, the bump to Java 8 was considered a bold move
> (for "Commons"). :-}
>
> If we are sure that Java 11 is no problem for anyone who'd go
> through the upgrade effort, then indeed why not?
>
> Gilles
>
> > As Java 17 starting ramp down starts today I believe so in 3 months we
> > will have 3 LTS (1.8, 11 and 17) releases. So technically Java 18
> > development starts tomorrow and I expect 1.8 will be dropped shortly
> > from backwards support as they want to get off the classpath fully and
> > onto the modules path.
> >
> > Anyway, just a thought.
> >
> > John
> >
> > On Thu, 10 Jun 2021 at 12:05, sebb <se...@gmail.com> wrote:
> > >
> > > Thanks.
> > >
> > > I've updated the RELEASE-NOTES accordingly (feel free to tweak the
> text)
> > >
> > > On Thu, 10 Jun 2021 at 00:58, Alex Herbert <al...@gmail.com>
> wrote:
> > > >
> > > > I have removed the requirement for Java 9 from the build. It is
> still used
> > > > in the performance testing module.
> > > >
> > > > Alex
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>

Re: [EXTERNAL] Re: [Numbers][All] Separate Java target version for "src/test"

Posted by Gilles Sadowski <gi...@gmail.com>.
Le jeu. 10 juin 2021 à 14:42, John Patrick <nh...@gmail.com> a écrit :
>
> If the tests are valid and useful once post Java 1.8, what about
> starting the next release branch where the min version bumps to Java
> 11.

[Numbers] and related components were meant to replace and
improve some functionalities provided in [Math] v3.6.1 whose
target was Java 5 (!).
A few years ago, the bump to Java 8 was considered a bold move
(for "Commons"). :-}

If we are sure that Java 11 is no problem for anyone who'd go
through the upgrade effort, then indeed why not?

Gilles

> As Java 17 starting ramp down starts today I believe so in 3 months we
> will have 3 LTS (1.8, 11 and 17) releases. So technically Java 18
> development starts tomorrow and I expect 1.8 will be dropped shortly
> from backwards support as they want to get off the classpath fully and
> onto the modules path.
>
> Anyway, just a thought.
>
> John
>
> On Thu, 10 Jun 2021 at 12:05, sebb <se...@gmail.com> wrote:
> >
> > Thanks.
> >
> > I've updated the RELEASE-NOTES accordingly (feel free to tweak the text)
> >
> > On Thu, 10 Jun 2021 at 00:58, Alex Herbert <al...@gmail.com> wrote:
> > >
> > > I have removed the requirement for Java 9 from the build. It is still used
> > > in the performance testing module.
> > >
> > > Alex

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Re: [EXTERNAL] Re: [Numbers][All] Separate Java target version for "src/test"

Posted by John Patrick <nh...@gmail.com>.
If the tests are valid and useful once post Java 1.8, what about
starting the next release branch where the min version bumps to Java
11.
As Java 17 starting ramp down starts today I believe so in 3 months we
will have 3 LTS (1.8, 11 and 17) releases. So technically Java 18
development starts tomorrow and I expect 1.8 will be dropped shortly
from backwards support as they want to get off the classpath fully and
onto the modules path.

Anyway, just a thought.

John

On Thu, 10 Jun 2021 at 12:05, sebb <se...@gmail.com> wrote:
>
> Thanks.
>
> I've updated the RELEASE-NOTES accordingly (feel free to tweak the text)
>
> On Thu, 10 Jun 2021 at 00:58, Alex Herbert <al...@gmail.com> wrote:
> >
> > I have removed the requirement for Java 9 from the build. It is still used
> > in the performance testing module.
> >
> > Alex
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Re: [EXTERNAL] Re: [Numbers][All] Separate Java target version for "src/test"

Posted by Gilles Sadowski <gi...@gmail.com>.
Le jeu. 10 juin 2021 à 13:05, sebb <se...@gmail.com> a écrit :
>
> Thanks.
>
> I've updated the RELEASE-NOTES accordingly (feel free to tweak the text)

AFAIK, this is an auto-generated file (from changes.xml).

Gilles

>
> On Thu, 10 Jun 2021 at 00:58, Alex Herbert <al...@gmail.com> wrote:
> >
> > I have removed the requirement for Java 9 from the build. It is still used
> > in the performance testing module.
> >
> > Alex

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Re: [EXTERNAL] Re: [Numbers][All] Separate Java target version for "src/test"

Posted by sebb <se...@gmail.com>.
Thanks.

I've updated the RELEASE-NOTES accordingly (feel free to tweak the text)

On Thu, 10 Jun 2021 at 00:58, Alex Herbert <al...@gmail.com> wrote:
>
> I have removed the requirement for Java 9 from the build. It is still used
> in the performance testing module.
>
> Alex

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Re: [EXTERNAL] Re: [Numbers][All] Separate Java target version for "src/test"

Posted by Alex Herbert <al...@gmail.com>.
I have removed the requirement for Java 9 from the build. It is still used
in the performance testing module.

Alex

Re: [EXTERNAL] Re: [Numbers][All] Separate Java target version for "src/test"

Posted by "Strauss, Randy (ARC-TI)[KBR Wyle Services, LLC]" <ra...@nasa.gov.INVALID>.
Note that the test could inspect the java version,
or use reflection to see if the method BigDecimal.sqrt() exists...
-r
Randy Strauss, cell: 650-861-1537

On 6/9/21, 2:57 PM, "sebb" <se...@gmail.com> wrote:

    On Wed, 9 Jun 2021 at 19:58, Alex Herbert <al...@gmail.com> wrote:
    >
    > On Wed, 9 Jun 2021 at 17:56, sebb <se...@gmail.com> wrote:
    >
    > > On Wed, 9 Jun 2021 at 17:26, Alex Herbert <al...@gmail.com>
    > > wrote:
    > > >
    > > > On Wed, 9 Jun 2021 at 17:03, John Patrick <nh...@gmail.com>
    > > wrote:
    > > >
    > > > > Have you tried "9" instead of "1.9"?
    > > > >
    > > >
    > > > I've corrected that in the pom, thanks.
    > > >
    > > > I think the issue is that Gilles used JDK 8 to try and build it. You can
    > > > run using the project's main artifacts using JDK 8, but the build now
    > > > requires JDK 9 for the tests and JMH performance tests.
    > >
    > > That seems wrong. If the code targets Java 8, it must be possible to
    > > test it using Java 8.
    > >
    > > It's possibly OK to require JDK 9 for performance tests.
    > >
    >
    > The test is using JDK 9 for the BigDecimal sqrt method. This is used to
    > compute the exact answer for a Euclidean norm on random input. Since the
    > input is random the answers cannot be hard-coded into the test. So this
    > test is not possible on JDK 8. The alternative is if the exact computation
    > is done using BigDecimal, converted to double, and then a sqrt computed. We
    > could change to that instead if there are strong objections here against
    > java 9.

    I certainly object.

    >
    > The issue with requiring a higher JDK than the target is similar to using
    > JDK 8 so that JUnit 5 can be used for the test suite to test code that
    > targets a level lower than 1.8.

    IMO that would be wrong as well.

    Someone wanting to use the source on its minimum supported version
    must be able to run the tests using that same version.

    > Alex

    ---------------------------------------------------------------------
    To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
    For additional commands, e-mail: dev-help@commons.apache.org



Re: [Numbers][All] Separate Java target version for "src/test"

Posted by sebb <se...@gmail.com>.
On Wed, 9 Jun 2021 at 19:58, Alex Herbert <al...@gmail.com> wrote:
>
> On Wed, 9 Jun 2021 at 17:56, sebb <se...@gmail.com> wrote:
>
> > On Wed, 9 Jun 2021 at 17:26, Alex Herbert <al...@gmail.com>
> > wrote:
> > >
> > > On Wed, 9 Jun 2021 at 17:03, John Patrick <nh...@gmail.com>
> > wrote:
> > >
> > > > Have you tried "9" instead of "1.9"?
> > > >
> > >
> > > I've corrected that in the pom, thanks.
> > >
> > > I think the issue is that Gilles used JDK 8 to try and build it. You can
> > > run using the project's main artifacts using JDK 8, but the build now
> > > requires JDK 9 for the tests and JMH performance tests.
> >
> > That seems wrong. If the code targets Java 8, it must be possible to
> > test it using Java 8.
> >
> > It's possibly OK to require JDK 9 for performance tests.
> >
>
> The test is using JDK 9 for the BigDecimal sqrt method. This is used to
> compute the exact answer for a Euclidean norm on random input. Since the
> input is random the answers cannot be hard-coded into the test. So this
> test is not possible on JDK 8. The alternative is if the exact computation
> is done using BigDecimal, converted to double, and then a sqrt computed. We
> could change to that instead if there are strong objections here against
> java 9.

I certainly object.

>
> The issue with requiring a higher JDK than the target is similar to using
> JDK 8 so that JUnit 5 can be used for the test suite to test code that
> targets a level lower than 1.8.

IMO that would be wrong as well.

Someone wanting to use the source on its minimum supported version
must be able to run the tests using that same version.

> Alex

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Re: [Numbers][All] Separate Java target version for "src/test"

Posted by Alex Herbert <al...@gmail.com>.
On Wed, 9 Jun 2021 at 17:56, sebb <se...@gmail.com> wrote:

> On Wed, 9 Jun 2021 at 17:26, Alex Herbert <al...@gmail.com>
> wrote:
> >
> > On Wed, 9 Jun 2021 at 17:03, John Patrick <nh...@gmail.com>
> wrote:
> >
> > > Have you tried "9" instead of "1.9"?
> > >
> >
> > I've corrected that in the pom, thanks.
> >
> > I think the issue is that Gilles used JDK 8 to try and build it. You can
> > run using the project's main artifacts using JDK 8, but the build now
> > requires JDK 9 for the tests and JMH performance tests.
>
> That seems wrong. If the code targets Java 8, it must be possible to
> test it using Java 8.
>
> It's possibly OK to require JDK 9 for performance tests.
>

The test is using JDK 9 for the BigDecimal sqrt method. This is used to
compute the exact answer for a Euclidean norm on random input. Since the
input is random the answers cannot be hard-coded into the test. So this
test is not possible on JDK 8. The alternative is if the exact computation
is done using BigDecimal, converted to double, and then a sqrt computed. We
could change to that instead if there are strong objections here against
java 9.

The issue with requiring a higher JDK than the target is similar to using
JDK 8 so that JUnit 5 can be used for the test suite to test code that
targets a level lower than 1.8.

Alex

Re: [Numbers][All] Separate Java target version for "src/test"

Posted by sebb <se...@gmail.com>.
On Wed, 9 Jun 2021 at 17:26, Alex Herbert <al...@gmail.com> wrote:
>
> On Wed, 9 Jun 2021 at 17:03, John Patrick <nh...@gmail.com> wrote:
>
> > Have you tried "9" instead of "1.9"?
> >
>
> I've corrected that in the pom, thanks.
>
> I think the issue is that Gilles used JDK 8 to try and build it. You can
> run using the project's main artifacts using JDK 8, but the build now
> requires JDK 9 for the tests and JMH performance tests.

That seems wrong. If the code targets Java 8, it must be possible to
test it using Java 8.

It's possibly OK to require JDK 9 for performance tests.

> I've
> successfully used JDK 9 and JDK 11 for the build.
>
> Travis CI is using JDK 11 and the Jenkins server is using JDK 9 for the
> main build and JDK 11 for the sonarcloud analysis build.
>
> Alex

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Re: [Numbers][All] Separate Java target version for "src/test"

Posted by Alex Herbert <al...@gmail.com>.
On Wed, 9 Jun 2021 at 17:03, John Patrick <nh...@gmail.com> wrote:

> Have you tried "9" instead of "1.9"?
>

I've corrected that in the pom, thanks.

I think the issue is that Gilles used JDK 8 to try and build it. You can
run using the project's main artifacts using JDK 8, but the build now
requires JDK 9 for the tests and JMH performance tests. I've
successfully used JDK 9 and JDK 11 for the build.

Travis CI is using JDK 11 and the Jenkins server is using JDK 9 for the
main build and JDK 11 for the sonarcloud analysis build.

Alex

Re: [Numbers][All] Separate Java target version for "src/test"

Posted by John Patrick <nh...@gmail.com>.
Have you tried "9" instead of "1.9"?
I believe the 1.x was dropped with Java 9's release.
Also might want to bump it to Java 11 as that is a LTS release, as 9
was only supported for 6 months from september 2017 to march 2018.

Also with 9 and newer, maven.compiler.source/maven.compiler.target
have been replaced with maven.compiler.release. Not sure if the test
versions also changed or not.

I've no zero luck with a single pom with multiple src/test/java
directories, using different jdk's. The compiler supports toolchain
but when I last tried only for src/main directories, not for src/test
directories.

Also when the tests run they see everything in target/test-classes so
do you run them with 1.8 or 9?

JEP 238 supports multiple java versions in a single jar, but last time
i tried it appears to have a bug that the base version has to be java
9.

Not sure if the above helps or not, or give any insight.

John

On Wed, 9 Jun 2021 at 15:29, Gilles Sadowski <gi...@gmail.com> wrote:
>
> Hi.
>
> "Commons Numbers" POM of module "commons-numbers-core"
> contains
> ---CUT---
>     <!-- JDK 9+ required for BigDecimal.sqrt() method in unit tests. -->
>     <maven.compiler.testSource>1.9</maven.compiler.testSource>
>     <maven.compiler.testTarget>1.9</maven.compiler.testTarget>
> ---CUT---
>
> Running
> $ JAVA_HOME=/usr/lib/jvm/java-8-openjdk-amd64/ mvn test site site:stage
> fails:
> ---CUT---
> [...]
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-compiler-plugin:3.8.1:testCompile
> (default-testCompile) on project commons-numbers-core: Fatal error
> compiling: invalid target release: 1.9 -> [Help 1]
> ---CUT---
>
> Regards,
> Gilles
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org