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 <gi...@harfang.homelinux.org> on 2017/04/27 12:49:01 UTC

[Numbers] Java version?

Hi.

The POM indicates:

     <maven.compiler.source>1.6</maven.compiler.source>
     <maven.compiler.target>1.6</maven.compiler.target>

but also:

     <commons.release.desc>(requires Java 7+)</commons.release.desc>

Which is wrong?

Regards,
Gilles


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

Re: [Numbers] Java version?

Posted by Gilles <gi...@harfang.homelinux.org>.

On Mon, 1 May 2017 09:08:23 +1000, Peter Ansell wrote:
> Jenkins now requires Java-8 as its base runtime environment on the
> regular release channel, with its LTS channel moving to Java-8 in a
> few weeks:
>
> https://jenkins.io/blog/2017/04/10/jenkins-has-upgraded-to-java-8/

Thanks for the notice.

As Sebb aptly reminded, this is however independent of why we might
want a component to upgrade its Java version, but ...

> That one bit me, as there is a bug updating on older Ubuntu versions
> that don't carry a Java-8 JDK in their standard repositories so you
> need to pull in the webupd8 PPA or the openjdk PPA:
>
> https://issues.jenkins-ci.org/browse/JENKINS-43629
>
> The statistics that backed the Jenkins decision were interesting, but
> not necessarily relevant to other production applications:
>
> https://jenkins.io/blog/2017/01/17/Jenkins-is-upgrading-to-Java-8/

... this link is yet another rephrase of why a community-driven
project might want to keep up with its environment:
   "Being also a developer community, we want Jenkins to be
    appealing to contributors."


Regards,
Gilles

>
> Cheers,
>
> Peter
>
> On 1 May 2017 at 02:22, Matt Sicker <bo...@gmail.com> wrote:
>> Supporting Java 6 is going to continue to become harder and harder 
>> to do
>> with infrastructural upgrades across the board. Recent versions of 
>> Gradle
>> require Java 7 to run, for example, just like Jenkins, even though 
>> you can
>> still use those to compile for Java 6. Ant has finally moved on from 
>> the
>> Java 5 baseline, though IIRC, they jumped straight to Java 8. 
>> Considering
>> how long it was between Maven 3.3.9 and 3.5.0, I'm guessing the 
>> discussion
>> there about the baseline Java version is still ongoing.
>>
>> Really, what this is all pointing toward is that the greater Java 
>> developer
>> community is moving on from Java 6, and if we want to continue 
>> supporting
>> Java 6 in projects that otherwise shouldn't need anything newer, we 
>> may
>> need some better tooling or documented standards on how to continue 
>> doing
>> so. If Java 6 just never dies, then I almost think that we'll need 
>> to take
>> a leaf from the Javascript developer community and get some sort of
>> transpiler to support Java 6 using newer syntax and libraries (which 
>> could
>> be compile-time re-linked to compatibility libraries).
>>
>> On 30 April 2017 at 09:55, Gilles <gi...@harfang.homelinux.org> 
>> wrote:
>>
>>> On Sun, 30 Apr 2017 15:39:20 +0100, sebb wrote:
>>>
>>>> On 30 April 2017 at 15:32, Gilles <gi...@harfang.homelinux.org> 
>>>> wrote:
>>>>
>>>>> On Sun, 30 Apr 2017 14:49:56 +0100, sebb wrote:
>>>>>
>>>>>>
>>>>>> On 29 April 2017 at 19:10, Gilles <gi...@harfang.homelinux.org> 
>>>>>> wrote:
>>>>>>
>>>>>>>
>>>>>>> Hi.
>>>>>>>
>>>>>>> On Sat, 29 Apr 2017 09:46:56 -0400, Raymond DeCampo wrote:
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Please note I wrote an issue concerning this last week or so.
>>>>>>>>
>>>>>>>> https://issues.apache.org/jira/browse/NUMBERS-21
>>>>>>>>
>>>>>>>> I noticed when moving code from [math] to [numbers] that 
>>>>>>>> [math]
>>>>>>>> targets
>>>>>>>> 7.
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> As a general rule, this must formally asked on the "dev" ML.
>>>>>>> [And, we'll take for granted that if no one raises an objection
>>>>>>> within 72 hours, the proposal is accepted.]
>>>>>>>
>>>>>>> I had to make some minor downgrades in the code (use of diamond
>>>>>>>> operator).
>>>>>>>>
>>>>>>>> Given that [math] targets Java 7 and [numbers] is based on it, 
>>>>>>>> I see
>>>>>>>> no
>>>>>>>> reason [numbers] shouldn't target 7 as well.
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> That's fine with me; however let's note (for the record) that 
>>>>>>> the
>>>>>>> last official release of CM (3.6.1) was still Java 5 (five) 
>>>>>>> compatible.
>>>>>>> I don't think (TBC) that any of the CM codes intended (as of 
>>>>>>> now) for
>>>>>>> inclusion _requires_ Java 7.
>>>>>>>
>>>>>>> Hence my question about the necessity (seems not) or 
>>>>>>> willingness
>>>>>>> (could well be, if just for the comfort of contributors) to 
>>>>>>> upgrade.
>>>>>>>
>>>>>>> Now, concretely, you could make the "downgrades" and the code 
>>>>>>> is
>>>>>>> now Java 6 compatible.
>>>>>>> However, as concretely, it is not obvious that we want to loose
>>>>>>> more time fiddling with Jenkins to make it perform the build of
>>>>>>> code targeted to old Java.
>>>>>>>
>>>>>>
>>>>>>
>>>>>> IMO it is wrong for Jenkins to dictate the Java compat level of 
>>>>>> the
>>>>>> items it builds.
>>>>>>
>>>>>
>>>>>
>>>>> I agree.
>>>>>
>>>>> Besides, it is not difficult to do.
>>>>>>
>>>>>
>>>>>
>>>>> Then why doesn't INFRA do it when they perform an upgrade that
>>>>> breaks what used to work?
>>>>>
>>>>
>>>> Don't ask me, ask them...
>>>>
>>>
>>> I first asked here because I might have missed an announcement
>>> explaining how to upgrade the config.  [I seem to recall having
>>> done what was required when the issue with Java 6 was first
>>> mentioned; then it broke again.]
>>>
>>>
>>>> Help welcome, since I must have missed the "easy" part in my
>>>>> attempts to fix it...
>>>>>
>>>>
>>>> Which job is failing?
>>>>
>>>
>>> I've just seen that you fixed it for "RNG". Thanks!
>>> I've reviewed the changes and did the same in "Numbers".
>>> Fixed now!
>>>
>>> Thanks,
>>> Gilles
>>>
>>>
>>>
>>>> Gilles
>>>>>
>>>>>
>>>>>
>>>>>>
>>>>>>> Regards,
>>>>>>> Gilles
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> On Fri, Apr 28, 2017 at 6:30 PM, sebb <se...@gmail.com> 
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>> On 28 April 2017 at 16:05, Matt Sicker <bo...@gmail.com> 
>>>>>>>> wrote:
>>>>>>>>> > If you're going to build for Java 6 using Java 7, then you 
>>>>>>>>> should
>>>>>>>>> > really
>>>>>>>>> > use something like <
>>>>>>>>> > 
>>>>>>>>> http://www.mojohaus.org/animal-sniffer/animal-sniffer-maven-
>>>>>>>>> plugin/>
>>>>>>>>> > to
>>>>>>>>> > prevent accidental usage of Java 7.
>>>>>>>>>
>>>>>>>>> And/Or actually use Java 6 to compile/test, which is pretty 
>>>>>>>>> easy to
>>>>>>>>> do
>>>>>>>>> using the -Pjava-1.6 profile.
>>>>>>>>>
>>>>>>>>> > On 28 April 2017 at 09:51, sebb <se...@gmail.com> wrote:
>>>>>>>>> >
>>>>>>>>> >> On 28 April 2017 at 13:01, Gilles 
>>>>>>>>> <gi...@harfang.homelinux.org>
>>>>>>>>> >> wrote:
>>>>>>>>> >> > Hi.
>>>>>>>>> >> >
>>>>>>>>> >> > On Thu, 27 Apr 2017 08:42:36 -0700, Gary Gregory wrote:
>>>>>>>>> >> >>
>>>>>>>>> >> >> On Apr 27, 2017 8:21 AM, "Gilles" <
>>>>>>>>> gilles@harfang.homelinux.org>
>>>>>>>>> wrote:
>>>>>>>>> >> >>
>>>>>>>>> >> >> On Thu, 27 Apr 2017 10:10:57 -0500, Matt Sicker wrote:
>>>>>>>>> >> >>
>>>>>>>>> >> >>> Choosing Java 8 or 7 for a new component depends on 
>>>>>>>>> the APIs
>>>>>>>>> you
>>>>>>>>> want
>>>>>>>>> >> to
>>>>>>>>> >> >>> use for it more so than what's current.
>>>>>>>>> >> >>>
>>>>>>>>> >> >>
>>>>>>>>> >> >> Indeed, the question could be rephrased as: Is there 
>>>>>>>>> anything
>>>>>>>>> to
>>>>>>>>> loose
>>>>>>>>> >> >> (for a new component) if we allow the larger API of 
>>>>>>>>> Java 8?
>>>>>>>>> >> >>
>>>>>>>>> >> >>
>>>>>>>>> >> >> I hear people are still using Java
>>>>>>>>> >> >>>
>>>>>>>>> >> >>> 6, but I doubt those projects are adapting new 
>>>>>>>>> libraries or
>>>>>>>>> upgrading
>>>>>>>>> >> any
>>>>>>>>> >> >>> of their dependencies as it is...
>>>>>>>>> >> >>>
>>>>>>>>> >> >>
>>>>>>>>> >> >> That has seemed logical to me for a long time...
>>>>>>>>> >> >>
>>>>>>>>> >> >>
>>>>>>>>> >> >> +1
>>>>>>>>> >> >>
>>>>>>>>> >> >> I say pick the version you think is best.
>>>>>>>>> >> >
>>>>>>>>> >> >
>>>>>>>>> >> > At this point, I can't say exactly.
>>>>>>>>> >> > The current code doesn't seem to need Java APIs beyond 
>>>>>>>>> 6, but
>>>>>>>>> >> > other
>>>>>>>>> >> > utilities yet to be added might benefit.
>>>>>>>>> >> > The only argument for leaving Java 6 is that we have to 
>>>>>>>>> go
>>>>>>>>> through
>>>>>>>>> >> > hoops with the Jenkins configuration.
>>>>>>>>> >>
>>>>>>>>> >> That is not an argument for upping the Java version
>>>>>>>>> >>
>>>>>>>>> >> > Currently it fails in a way that looks cryptic to me.
>>>>>>>>> >>
>>>>>>>>> >> That's because Jenkins now requires Java 7 to run Maven 
>>>>>>>>> jobs,
>>>>>>>>> though
>>>>>>>>> >> it does not seem to need it for all job types.
>>>>>>>>> >>
>>>>>>>>> >> > So, unless someone can fix it, I'll bump the dependency 
>>>>>>>>> to Java
>>>>>>>>> 7.
>>>>>>>>> >>
>>>>>>>>> >> Huh?
>>>>>>>>> >> Surely you can just tell Jenkins to use Java 7 to build 
>>>>>>>>> and test?
>>>>>>>>> >> There's no need for the source to be updated as well 
>>>>>>>>> (there might
>>>>>>>>> be
>>>>>>>>> >> some Javadoc warnings, I suppose, but those can be fixed 
>>>>>>>>> without
>>>>>>>>> >> compromising Java 6 compat.)
>>>>>>>>> >>
>>>>>>>>> >> But it's pretty easy to fix so it builds and tests using 
>>>>>>>>> Java 6 -
>>>>>>>>> >> which job is it?
>>>>>>>>> >>
>>>>>>>>> >> > Regards,
>>>>>>>>> >> > Gilles
>>>>>>>>> >> >
>>>>>>>>> >> >
>>>>>>>>> >> >
>>>>>>>>> >> >>
>>>>>>>>> >> >> Gary
>>>>>>>>> >> >>
>>>>>>>>> >> >>
>>>>>>>>> >> >> Regards,
>>>>>>>>> >> >> Gilles
>>>>>>>>> >> >>
>>>>>>>>> >> >>
>>>>>>>>> >> >> On 27 April 2017 at 09:41, Gilles <
>>>>>>>>> gilles@harfang.homelinux.org>
>>>>>>>>> wrote:
>>>>>>>>> >> >>>
>>>>>>>>> >> >>>
>>>>>>>>> >> >>> On Thu, 27 Apr 2017 14:49:01 +0200, Gilles wrote:
>>>>>>>>> >> >>>>
>>>>>>>>> >> >>>>
>>>>>>>>> >> >>>> Hi.
>>>>>>>>> >> >>>>>
>>>>>>>>> >> >>>>>
>>>>>>>>> >> >>>>> The POM indicates:
>>>>>>>>> >> >>>>>
>>>>>>>>> >> >>>>>     
>>>>>>>>> <maven.compiler.source>1.6</maven.compiler.source>
>>>>>>>>> >> >>>>>     
>>>>>>>>> <maven.compiler.target>1.6</maven.compiler.target>
>>>>>>>>> >> >>>>>
>>>>>>>>> >> >>>>> but also:
>>>>>>>>> >> >>>>>
>>>>>>>>> >> >>>>>     <commons.release.desc>(requires Java
>>>>>>>>> 7+)</commons.release.desc>
>>>>>>>>> >> >>>>>
>>>>>>>>> >> >>>>> Which is wrong?
>>>>>>>>> >> >>>>>
>>>>>>>>> >> >>>>>
>>>>>>>>> >> >>>>> Also, please not that keeping 1.6 compatibility 
>>>>>>>>> seems to
>>>>>>>>> complicate
>>>>>>>>> >> >>>>
>>>>>>>>> >> >>>> the Jenkins configuration:
>>>>>>>>> >> >>>>   https://builds.apache.org/vie
>>>>>>>>> w/Apache%20Commons/job/Commons_
>>>>>>>>> >> >>>> Numbers/14/console
>>>>>>>>> >> >>>>
>>>>>>>>> >> >>>> For a new component, shouldn't we just go to Java 8?
>>>>>>>>> >> >>>>
>>>>>>>>> >> >>>>
>>>>>>>>> >> >>>> Gilles
>>>>>>>>> >> >>>>
>>>>>>>>> >> >
>>>>>>>>> >> >
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>
>>> 
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>
>>
>>
>> --
>> Matt Sicker <bo...@gmail.com>
>
> ---------------------------------------------------------------------
> 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: [Numbers] Java version?

Posted by Peter Ansell <an...@gmail.com>.

Jenkins now requires Java-8 as its base runtime environment on the
regular release channel, with its LTS channel moving to Java-8 in a
few weeks:

https://jenkins.io/blog/2017/04/10/jenkins-has-upgraded-to-java-8/

That one bit me, as there is a bug updating on older Ubuntu versions
that don't carry a Java-8 JDK in their standard repositories so you
need to pull in the webupd8 PPA or the openjdk PPA:

https://issues.jenkins-ci.org/browse/JENKINS-43629

The statistics that backed the Jenkins decision were interesting, but
not necessarily relevant to other production applications:

https://jenkins.io/blog/2017/01/17/Jenkins-is-upgrading-to-Java-8/

Cheers,

Peter

On 1 May 2017 at 02:22, Matt Sicker <bo...@gmail.com> wrote:
> Supporting Java 6 is going to continue to become harder and harder to do
> with infrastructural upgrades across the board. Recent versions of Gradle
> require Java 7 to run, for example, just like Jenkins, even though you can
> still use those to compile for Java 6. Ant has finally moved on from the
> Java 5 baseline, though IIRC, they jumped straight to Java 8. Considering
> how long it was between Maven 3.3.9 and 3.5.0, I'm guessing the discussion
> there about the baseline Java version is still ongoing.
>
> Really, what this is all pointing toward is that the greater Java developer
> community is moving on from Java 6, and if we want to continue supporting
> Java 6 in projects that otherwise shouldn't need anything newer, we may
> need some better tooling or documented standards on how to continue doing
> so. If Java 6 just never dies, then I almost think that we'll need to take
> a leaf from the Javascript developer community and get some sort of
> transpiler to support Java 6 using newer syntax and libraries (which could
> be compile-time re-linked to compatibility libraries).
>
> On 30 April 2017 at 09:55, Gilles <gi...@harfang.homelinux.org> wrote:
>
>> On Sun, 30 Apr 2017 15:39:20 +0100, sebb wrote:
>>
>>> On 30 April 2017 at 15:32, Gilles <gi...@harfang.homelinux.org> wrote:
>>>
>>>> On Sun, 30 Apr 2017 14:49:56 +0100, sebb wrote:
>>>>
>>>>>
>>>>> On 29 April 2017 at 19:10, Gilles <gi...@harfang.homelinux.org> wrote:
>>>>>
>>>>>>
>>>>>> Hi.
>>>>>>
>>>>>> On Sat, 29 Apr 2017 09:46:56 -0400, Raymond DeCampo wrote:
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Please note I wrote an issue concerning this last week or so.
>>>>>>>
>>>>>>> https://issues.apache.org/jira/browse/NUMBERS-21
>>>>>>>
>>>>>>> I noticed when moving code from [math] to [numbers] that [math]
>>>>>>> targets
>>>>>>> 7.
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> As a general rule, this must formally asked on the "dev" ML.
>>>>>> [And, we'll take for granted that if no one raises an objection
>>>>>> within 72 hours, the proposal is accepted.]
>>>>>>
>>>>>> I had to make some minor downgrades in the code (use of diamond
>>>>>>> operator).
>>>>>>>
>>>>>>> Given that [math] targets Java 7 and [numbers] is based on it, I see
>>>>>>> no
>>>>>>> reason [numbers] shouldn't target 7 as well.
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> That's fine with me; however let's note (for the record) that the
>>>>>> last official release of CM (3.6.1) was still Java 5 (five) compatible.
>>>>>> I don't think (TBC) that any of the CM codes intended (as of now) for
>>>>>> inclusion _requires_ Java 7.
>>>>>>
>>>>>> Hence my question about the necessity (seems not) or willingness
>>>>>> (could well be, if just for the comfort of contributors) to upgrade.
>>>>>>
>>>>>> Now, concretely, you could make the "downgrades" and the code is
>>>>>> now Java 6 compatible.
>>>>>> However, as concretely, it is not obvious that we want to loose
>>>>>> more time fiddling with Jenkins to make it perform the build of
>>>>>> code targeted to old Java.
>>>>>>
>>>>>
>>>>>
>>>>> IMO it is wrong for Jenkins to dictate the Java compat level of the
>>>>> items it builds.
>>>>>
>>>>
>>>>
>>>> I agree.
>>>>
>>>> Besides, it is not difficult to do.
>>>>>
>>>>
>>>>
>>>> Then why doesn't INFRA do it when they perform an upgrade that
>>>> breaks what used to work?
>>>>
>>>
>>> Don't ask me, ask them...
>>>
>>
>> I first asked here because I might have missed an announcement
>> explaining how to upgrade the config.  [I seem to recall having
>> done what was required when the issue with Java 6 was first
>> mentioned; then it broke again.]
>>
>>
>>> Help welcome, since I must have missed the "easy" part in my
>>>> attempts to fix it...
>>>>
>>>
>>> Which job is failing?
>>>
>>
>> I've just seen that you fixed it for "RNG". Thanks!
>> I've reviewed the changes and did the same in "Numbers".
>> Fixed now!
>>
>> Thanks,
>> Gilles
>>
>>
>>
>>> Gilles
>>>>
>>>>
>>>>
>>>>>
>>>>>> Regards,
>>>>>> Gilles
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> On Fri, Apr 28, 2017 at 6:30 PM, sebb <se...@gmail.com> wrote:
>>>>>>>
>>>>>>> On 28 April 2017 at 16:05, Matt Sicker <bo...@gmail.com> wrote:
>>>>>>>> > If you're going to build for Java 6 using Java 7, then you should
>>>>>>>> > really
>>>>>>>> > use something like <
>>>>>>>> > http://www.mojohaus.org/animal-sniffer/animal-sniffer-maven-
>>>>>>>> plugin/>
>>>>>>>> > to
>>>>>>>> > prevent accidental usage of Java 7.
>>>>>>>>
>>>>>>>> And/Or actually use Java 6 to compile/test, which is pretty easy to
>>>>>>>> do
>>>>>>>> using the -Pjava-1.6 profile.
>>>>>>>>
>>>>>>>> > On 28 April 2017 at 09:51, sebb <se...@gmail.com> wrote:
>>>>>>>> >
>>>>>>>> >> On 28 April 2017 at 13:01, Gilles <gi...@harfang.homelinux.org>
>>>>>>>> >> wrote:
>>>>>>>> >> > Hi.
>>>>>>>> >> >
>>>>>>>> >> > On Thu, 27 Apr 2017 08:42:36 -0700, Gary Gregory wrote:
>>>>>>>> >> >>
>>>>>>>> >> >> On Apr 27, 2017 8:21 AM, "Gilles" <
>>>>>>>> gilles@harfang.homelinux.org>
>>>>>>>> wrote:
>>>>>>>> >> >>
>>>>>>>> >> >> On Thu, 27 Apr 2017 10:10:57 -0500, Matt Sicker wrote:
>>>>>>>> >> >>
>>>>>>>> >> >>> Choosing Java 8 or 7 for a new component depends on the APIs
>>>>>>>> you
>>>>>>>> want
>>>>>>>> >> to
>>>>>>>> >> >>> use for it more so than what's current.
>>>>>>>> >> >>>
>>>>>>>> >> >>
>>>>>>>> >> >> Indeed, the question could be rephrased as: Is there anything
>>>>>>>> to
>>>>>>>> loose
>>>>>>>> >> >> (for a new component) if we allow the larger API of Java 8?
>>>>>>>> >> >>
>>>>>>>> >> >>
>>>>>>>> >> >> I hear people are still using Java
>>>>>>>> >> >>>
>>>>>>>> >> >>> 6, but I doubt those projects are adapting new libraries or
>>>>>>>> upgrading
>>>>>>>> >> any
>>>>>>>> >> >>> of their dependencies as it is...
>>>>>>>> >> >>>
>>>>>>>> >> >>
>>>>>>>> >> >> That has seemed logical to me for a long time...
>>>>>>>> >> >>
>>>>>>>> >> >>
>>>>>>>> >> >> +1
>>>>>>>> >> >>
>>>>>>>> >> >> I say pick the version you think is best.
>>>>>>>> >> >
>>>>>>>> >> >
>>>>>>>> >> > At this point, I can't say exactly.
>>>>>>>> >> > The current code doesn't seem to need Java APIs beyond 6, but
>>>>>>>> >> > other
>>>>>>>> >> > utilities yet to be added might benefit.
>>>>>>>> >> > The only argument for leaving Java 6 is that we have to go
>>>>>>>> through
>>>>>>>> >> > hoops with the Jenkins configuration.
>>>>>>>> >>
>>>>>>>> >> That is not an argument for upping the Java version
>>>>>>>> >>
>>>>>>>> >> > Currently it fails in a way that looks cryptic to me.
>>>>>>>> >>
>>>>>>>> >> That's because Jenkins now requires Java 7 to run Maven jobs,
>>>>>>>> though
>>>>>>>> >> it does not seem to need it for all job types.
>>>>>>>> >>
>>>>>>>> >> > So, unless someone can fix it, I'll bump the dependency to Java
>>>>>>>> 7.
>>>>>>>> >>
>>>>>>>> >> Huh?
>>>>>>>> >> Surely you can just tell Jenkins to use Java 7 to build and test?
>>>>>>>> >> There's no need for the source to be updated as well (there might
>>>>>>>> be
>>>>>>>> >> some Javadoc warnings, I suppose, but those can be fixed without
>>>>>>>> >> compromising Java 6 compat.)
>>>>>>>> >>
>>>>>>>> >> But it's pretty easy to fix so it builds and tests using Java 6 -
>>>>>>>> >> which job is it?
>>>>>>>> >>
>>>>>>>> >> > Regards,
>>>>>>>> >> > Gilles
>>>>>>>> >> >
>>>>>>>> >> >
>>>>>>>> >> >
>>>>>>>> >> >>
>>>>>>>> >> >> Gary
>>>>>>>> >> >>
>>>>>>>> >> >>
>>>>>>>> >> >> Regards,
>>>>>>>> >> >> Gilles
>>>>>>>> >> >>
>>>>>>>> >> >>
>>>>>>>> >> >> On 27 April 2017 at 09:41, Gilles <
>>>>>>>> gilles@harfang.homelinux.org>
>>>>>>>> wrote:
>>>>>>>> >> >>>
>>>>>>>> >> >>>
>>>>>>>> >> >>> On Thu, 27 Apr 2017 14:49:01 +0200, Gilles wrote:
>>>>>>>> >> >>>>
>>>>>>>> >> >>>>
>>>>>>>> >> >>>> Hi.
>>>>>>>> >> >>>>>
>>>>>>>> >> >>>>>
>>>>>>>> >> >>>>> The POM indicates:
>>>>>>>> >> >>>>>
>>>>>>>> >> >>>>>     <maven.compiler.source>1.6</maven.compiler.source>
>>>>>>>> >> >>>>>     <maven.compiler.target>1.6</maven.compiler.target>
>>>>>>>> >> >>>>>
>>>>>>>> >> >>>>> but also:
>>>>>>>> >> >>>>>
>>>>>>>> >> >>>>>     <commons.release.desc>(requires Java
>>>>>>>> 7+)</commons.release.desc>
>>>>>>>> >> >>>>>
>>>>>>>> >> >>>>> Which is wrong?
>>>>>>>> >> >>>>>
>>>>>>>> >> >>>>>
>>>>>>>> >> >>>>> Also, please not that keeping 1.6 compatibility seems to
>>>>>>>> complicate
>>>>>>>> >> >>>>
>>>>>>>> >> >>>> the Jenkins configuration:
>>>>>>>> >> >>>>   https://builds.apache.org/vie
>>>>>>>> w/Apache%20Commons/job/Commons_
>>>>>>>> >> >>>> Numbers/14/console
>>>>>>>> >> >>>>
>>>>>>>> >> >>>> For a new component, shouldn't we just go to Java 8?
>>>>>>>> >> >>>>
>>>>>>>> >> >>>>
>>>>>>>> >> >>>> Gilles
>>>>>>>> >> >>>>
>>>>>>>> >> >
>>>>>>>> >> >
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
>
> --
> Matt Sicker <bo...@gmail.com>

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

Re: [Numbers] Java version?

Posted by Matt Sicker <bo...@gmail.com>.

Supporting Java 6 is going to continue to become harder and harder to do
with infrastructural upgrades across the board. Recent versions of Gradle
require Java 7 to run, for example, just like Jenkins, even though you can
still use those to compile for Java 6. Ant has finally moved on from the
Java 5 baseline, though IIRC, they jumped straight to Java 8. Considering
how long it was between Maven 3.3.9 and 3.5.0, I'm guessing the discussion
there about the baseline Java version is still ongoing.

Really, what this is all pointing toward is that the greater Java developer
community is moving on from Java 6, and if we want to continue supporting
Java 6 in projects that otherwise shouldn't need anything newer, we may
need some better tooling or documented standards on how to continue doing
so. If Java 6 just never dies, then I almost think that we'll need to take
a leaf from the Javascript developer community and get some sort of
transpiler to support Java 6 using newer syntax and libraries (which could
be compile-time re-linked to compatibility libraries).

On 30 April 2017 at 09:55, Gilles <gi...@harfang.homelinux.org> wrote:

> On Sun, 30 Apr 2017 15:39:20 +0100, sebb wrote:
>
>> On 30 April 2017 at 15:32, Gilles <gi...@harfang.homelinux.org> wrote:
>>
>>> On Sun, 30 Apr 2017 14:49:56 +0100, sebb wrote:
>>>
>>>>
>>>> On 29 April 2017 at 19:10, Gilles <gi...@harfang.homelinux.org> wrote:
>>>>
>>>>>
>>>>> Hi.
>>>>>
>>>>> On Sat, 29 Apr 2017 09:46:56 -0400, Raymond DeCampo wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> Please note I wrote an issue concerning this last week or so.
>>>>>>
>>>>>> https://issues.apache.org/jira/browse/NUMBERS-21
>>>>>>
>>>>>> I noticed when moving code from [math] to [numbers] that [math]
>>>>>> targets
>>>>>> 7.
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> As a general rule, this must formally asked on the "dev" ML.
>>>>> [And, we'll take for granted that if no one raises an objection
>>>>> within 72 hours, the proposal is accepted.]
>>>>>
>>>>> I had to make some minor downgrades in the code (use of diamond
>>>>>> operator).
>>>>>>
>>>>>> Given that [math] targets Java 7 and [numbers] is based on it, I see
>>>>>> no
>>>>>> reason [numbers] shouldn't target 7 as well.
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> That's fine with me; however let's note (for the record) that the
>>>>> last official release of CM (3.6.1) was still Java 5 (five) compatible.
>>>>> I don't think (TBC) that any of the CM codes intended (as of now) for
>>>>> inclusion _requires_ Java 7.
>>>>>
>>>>> Hence my question about the necessity (seems not) or willingness
>>>>> (could well be, if just for the comfort of contributors) to upgrade.
>>>>>
>>>>> Now, concretely, you could make the "downgrades" and the code is
>>>>> now Java 6 compatible.
>>>>> However, as concretely, it is not obvious that we want to loose
>>>>> more time fiddling with Jenkins to make it perform the build of
>>>>> code targeted to old Java.
>>>>>
>>>>
>>>>
>>>> IMO it is wrong for Jenkins to dictate the Java compat level of the
>>>> items it builds.
>>>>
>>>
>>>
>>> I agree.
>>>
>>> Besides, it is not difficult to do.
>>>>
>>>
>>>
>>> Then why doesn't INFRA do it when they perform an upgrade that
>>> breaks what used to work?
>>>
>>
>> Don't ask me, ask them...
>>
>
> I first asked here because I might have missed an announcement
> explaining how to upgrade the config.  [I seem to recall having
> done what was required when the issue with Java 6 was first
> mentioned; then it broke again.]
>
>
>> Help welcome, since I must have missed the "easy" part in my
>>> attempts to fix it...
>>>
>>
>> Which job is failing?
>>
>
> I've just seen that you fixed it for "RNG". Thanks!
> I've reviewed the changes and did the same in "Numbers".
> Fixed now!
>
> Thanks,
> Gilles
>
>
>
>> Gilles
>>>
>>>
>>>
>>>>
>>>>> Regards,
>>>>> Gilles
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>
>>>>>> On Fri, Apr 28, 2017 at 6:30 PM, sebb <se...@gmail.com> wrote:
>>>>>>
>>>>>> On 28 April 2017 at 16:05, Matt Sicker <bo...@gmail.com> wrote:
>>>>>>> > If you're going to build for Java 6 using Java 7, then you should
>>>>>>> > really
>>>>>>> > use something like <
>>>>>>> > http://www.mojohaus.org/animal-sniffer/animal-sniffer-maven-
>>>>>>> plugin/>
>>>>>>> > to
>>>>>>> > prevent accidental usage of Java 7.
>>>>>>>
>>>>>>> And/Or actually use Java 6 to compile/test, which is pretty easy to
>>>>>>> do
>>>>>>> using the -Pjava-1.6 profile.
>>>>>>>
>>>>>>> > On 28 April 2017 at 09:51, sebb <se...@gmail.com> wrote:
>>>>>>> >
>>>>>>> >> On 28 April 2017 at 13:01, Gilles <gi...@harfang.homelinux.org>
>>>>>>> >> wrote:
>>>>>>> >> > Hi.
>>>>>>> >> >
>>>>>>> >> > On Thu, 27 Apr 2017 08:42:36 -0700, Gary Gregory wrote:
>>>>>>> >> >>
>>>>>>> >> >> On Apr 27, 2017 8:21 AM, "Gilles" <
>>>>>>> gilles@harfang.homelinux.org>
>>>>>>> wrote:
>>>>>>> >> >>
>>>>>>> >> >> On Thu, 27 Apr 2017 10:10:57 -0500, Matt Sicker wrote:
>>>>>>> >> >>
>>>>>>> >> >>> Choosing Java 8 or 7 for a new component depends on the APIs
>>>>>>> you
>>>>>>> want
>>>>>>> >> to
>>>>>>> >> >>> use for it more so than what's current.
>>>>>>> >> >>>
>>>>>>> >> >>
>>>>>>> >> >> Indeed, the question could be rephrased as: Is there anything
>>>>>>> to
>>>>>>> loose
>>>>>>> >> >> (for a new component) if we allow the larger API of Java 8?
>>>>>>> >> >>
>>>>>>> >> >>
>>>>>>> >> >> I hear people are still using Java
>>>>>>> >> >>>
>>>>>>> >> >>> 6, but I doubt those projects are adapting new libraries or
>>>>>>> upgrading
>>>>>>> >> any
>>>>>>> >> >>> of their dependencies as it is...
>>>>>>> >> >>>
>>>>>>> >> >>
>>>>>>> >> >> That has seemed logical to me for a long time...
>>>>>>> >> >>
>>>>>>> >> >>
>>>>>>> >> >> +1
>>>>>>> >> >>
>>>>>>> >> >> I say pick the version you think is best.
>>>>>>> >> >
>>>>>>> >> >
>>>>>>> >> > At this point, I can't say exactly.
>>>>>>> >> > The current code doesn't seem to need Java APIs beyond 6, but
>>>>>>> >> > other
>>>>>>> >> > utilities yet to be added might benefit.
>>>>>>> >> > The only argument for leaving Java 6 is that we have to go
>>>>>>> through
>>>>>>> >> > hoops with the Jenkins configuration.
>>>>>>> >>
>>>>>>> >> That is not an argument for upping the Java version
>>>>>>> >>
>>>>>>> >> > Currently it fails in a way that looks cryptic to me.
>>>>>>> >>
>>>>>>> >> That's because Jenkins now requires Java 7 to run Maven jobs,
>>>>>>> though
>>>>>>> >> it does not seem to need it for all job types.
>>>>>>> >>
>>>>>>> >> > So, unless someone can fix it, I'll bump the dependency to Java
>>>>>>> 7.
>>>>>>> >>
>>>>>>> >> Huh?
>>>>>>> >> Surely you can just tell Jenkins to use Java 7 to build and test?
>>>>>>> >> There's no need for the source to be updated as well (there might
>>>>>>> be
>>>>>>> >> some Javadoc warnings, I suppose, but those can be fixed without
>>>>>>> >> compromising Java 6 compat.)
>>>>>>> >>
>>>>>>> >> But it's pretty easy to fix so it builds and tests using Java 6 -
>>>>>>> >> which job is it?
>>>>>>> >>
>>>>>>> >> > Regards,
>>>>>>> >> > Gilles
>>>>>>> >> >
>>>>>>> >> >
>>>>>>> >> >
>>>>>>> >> >>
>>>>>>> >> >> Gary
>>>>>>> >> >>
>>>>>>> >> >>
>>>>>>> >> >> Regards,
>>>>>>> >> >> Gilles
>>>>>>> >> >>
>>>>>>> >> >>
>>>>>>> >> >> On 27 April 2017 at 09:41, Gilles <
>>>>>>> gilles@harfang.homelinux.org>
>>>>>>> wrote:
>>>>>>> >> >>>
>>>>>>> >> >>>
>>>>>>> >> >>> On Thu, 27 Apr 2017 14:49:01 +0200, Gilles wrote:
>>>>>>> >> >>>>
>>>>>>> >> >>>>
>>>>>>> >> >>>> Hi.
>>>>>>> >> >>>>>
>>>>>>> >> >>>>>
>>>>>>> >> >>>>> The POM indicates:
>>>>>>> >> >>>>>
>>>>>>> >> >>>>>     <maven.compiler.source>1.6</maven.compiler.source>
>>>>>>> >> >>>>>     <maven.compiler.target>1.6</maven.compiler.target>
>>>>>>> >> >>>>>
>>>>>>> >> >>>>> but also:
>>>>>>> >> >>>>>
>>>>>>> >> >>>>>     <commons.release.desc>(requires Java
>>>>>>> 7+)</commons.release.desc>
>>>>>>> >> >>>>>
>>>>>>> >> >>>>> Which is wrong?
>>>>>>> >> >>>>>
>>>>>>> >> >>>>>
>>>>>>> >> >>>>> Also, please not that keeping 1.6 compatibility seems to
>>>>>>> complicate
>>>>>>> >> >>>>
>>>>>>> >> >>>> the Jenkins configuration:
>>>>>>> >> >>>>   https://builds.apache.org/vie
>>>>>>> w/Apache%20Commons/job/Commons_
>>>>>>> >> >>>> Numbers/14/console
>>>>>>> >> >>>>
>>>>>>> >> >>>> For a new component, shouldn't we just go to Java 8?
>>>>>>> >> >>>>
>>>>>>> >> >>>>
>>>>>>> >> >>>> Gilles
>>>>>>> >> >>>>
>>>>>>> >> >
>>>>>>> >> >
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>


-- 
Matt Sicker <bo...@gmail.com>

Re: [Numbers] Java version?

Posted by Gilles <gi...@harfang.homelinux.org>.

On Sun, 30 Apr 2017 15:39:20 +0100, sebb wrote:
> On 30 April 2017 at 15:32, Gilles <gi...@harfang.homelinux.org> 
> wrote:
>> On Sun, 30 Apr 2017 14:49:56 +0100, sebb wrote:
>>>
>>> On 29 April 2017 at 19:10, Gilles <gi...@harfang.homelinux.org> 
>>> wrote:
>>>>
>>>> Hi.
>>>>
>>>> On Sat, 29 Apr 2017 09:46:56 -0400, Raymond DeCampo wrote:
>>>>>
>>>>>
>>>>> Please note I wrote an issue concerning this last week or so.
>>>>>
>>>>> https://issues.apache.org/jira/browse/NUMBERS-21
>>>>>
>>>>> I noticed when moving code from [math] to [numbers] that [math] 
>>>>> targets
>>>>> 7.
>>>>
>>>>
>>>>
>>>> As a general rule, this must formally asked on the "dev" ML.
>>>> [And, we'll take for granted that if no one raises an objection
>>>> within 72 hours, the proposal is accepted.]
>>>>
>>>>> I had to make some minor downgrades in the code (use of diamond
>>>>> operator).
>>>>>
>>>>> Given that [math] targets Java 7 and [numbers] is based on it, I 
>>>>> see no
>>>>> reason [numbers] shouldn't target 7 as well.
>>>>
>>>>
>>>>
>>>> That's fine with me; however let's note (for the record) that the
>>>> last official release of CM (3.6.1) was still Java 5 (five) 
>>>> compatible.
>>>> I don't think (TBC) that any of the CM codes intended (as of now) 
>>>> for
>>>> inclusion _requires_ Java 7.
>>>>
>>>> Hence my question about the necessity (seems not) or willingness
>>>> (could well be, if just for the comfort of contributors) to 
>>>> upgrade.
>>>>
>>>> Now, concretely, you could make the "downgrades" and the code is
>>>> now Java 6 compatible.
>>>> However, as concretely, it is not obvious that we want to loose
>>>> more time fiddling with Jenkins to make it perform the build of
>>>> code targeted to old Java.
>>>
>>>
>>> IMO it is wrong for Jenkins to dictate the Java compat level of the
>>> items it builds.
>>
>>
>> I agree.
>>
>>> Besides, it is not difficult to do.
>>
>>
>> Then why doesn't INFRA do it when they perform an upgrade that
>> breaks what used to work?
>
> Don't ask me, ask them...

I first asked here because I might have missed an announcement
explaining how to upgrade the config.  [I seem to recall having
done what was required when the issue with Java 6 was first
mentioned; then it broke again.]

>
>> Help welcome, since I must have missed the "easy" part in my
>> attempts to fix it...
>
> Which job is failing?

I've just seen that you fixed it for "RNG". Thanks!
I've reviewed the changes and did the same in "Numbers".
Fixed now!

Thanks,
Gilles

>
>> Gilles
>>
>>
>>>
>>>>
>>>> Regards,
>>>> Gilles
>>>>
>>>>
>>>>
>>>>>
>>>>>
>>>>> On Fri, Apr 28, 2017 at 6:30 PM, sebb <se...@gmail.com> wrote:
>>>>>
>>>>>> On 28 April 2017 at 16:05, Matt Sicker <bo...@gmail.com> wrote:
>>>>>> > If you're going to build for Java 6 using Java 7, then you 
>>>>>> should
>>>>>> > really
>>>>>> > use something like <
>>>>>> > 
>>>>>> http://www.mojohaus.org/animal-sniffer/animal-sniffer-maven-plugin/>
>>>>>> > to
>>>>>> > prevent accidental usage of Java 7.
>>>>>>
>>>>>> And/Or actually use Java 6 to compile/test, which is pretty easy 
>>>>>> to do
>>>>>> using the -Pjava-1.6 profile.
>>>>>>
>>>>>> > On 28 April 2017 at 09:51, sebb <se...@gmail.com> wrote:
>>>>>> >
>>>>>> >> On 28 April 2017 at 13:01, Gilles 
>>>>>> <gi...@harfang.homelinux.org>
>>>>>> >> wrote:
>>>>>> >> > Hi.
>>>>>> >> >
>>>>>> >> > On Thu, 27 Apr 2017 08:42:36 -0700, Gary Gregory wrote:
>>>>>> >> >>
>>>>>> >> >> On Apr 27, 2017 8:21 AM, "Gilles" 
>>>>>> <gi...@harfang.homelinux.org>
>>>>>> wrote:
>>>>>> >> >>
>>>>>> >> >> On Thu, 27 Apr 2017 10:10:57 -0500, Matt Sicker wrote:
>>>>>> >> >>
>>>>>> >> >>> Choosing Java 8 or 7 for a new component depends on the 
>>>>>> APIs you
>>>>>> want
>>>>>> >> to
>>>>>> >> >>> use for it more so than what's current.
>>>>>> >> >>>
>>>>>> >> >>
>>>>>> >> >> Indeed, the question could be rephrased as: Is there 
>>>>>> anything to
>>>>>> loose
>>>>>> >> >> (for a new component) if we allow the larger API of Java 
>>>>>> 8?
>>>>>> >> >>
>>>>>> >> >>
>>>>>> >> >> I hear people are still using Java
>>>>>> >> >>>
>>>>>> >> >>> 6, but I doubt those projects are adapting new libraries 
>>>>>> or
>>>>>> upgrading
>>>>>> >> any
>>>>>> >> >>> of their dependencies as it is...
>>>>>> >> >>>
>>>>>> >> >>
>>>>>> >> >> That has seemed logical to me for a long time...
>>>>>> >> >>
>>>>>> >> >>
>>>>>> >> >> +1
>>>>>> >> >>
>>>>>> >> >> I say pick the version you think is best.
>>>>>> >> >
>>>>>> >> >
>>>>>> >> > At this point, I can't say exactly.
>>>>>> >> > The current code doesn't seem to need Java APIs beyond 6, 
>>>>>> but
>>>>>> >> > other
>>>>>> >> > utilities yet to be added might benefit.
>>>>>> >> > The only argument for leaving Java 6 is that we have to go 
>>>>>> through
>>>>>> >> > hoops with the Jenkins configuration.
>>>>>> >>
>>>>>> >> That is not an argument for upping the Java version
>>>>>> >>
>>>>>> >> > Currently it fails in a way that looks cryptic to me.
>>>>>> >>
>>>>>> >> That's because Jenkins now requires Java 7 to run Maven jobs, 
>>>>>> though
>>>>>> >> it does not seem to need it for all job types.
>>>>>> >>
>>>>>> >> > So, unless someone can fix it, I'll bump the dependency to 
>>>>>> Java 7.
>>>>>> >>
>>>>>> >> Huh?
>>>>>> >> Surely you can just tell Jenkins to use Java 7 to build and 
>>>>>> test?
>>>>>> >> There's no need for the source to be updated as well (there 
>>>>>> might be
>>>>>> >> some Javadoc warnings, I suppose, but those can be fixed 
>>>>>> without
>>>>>> >> compromising Java 6 compat.)
>>>>>> >>
>>>>>> >> But it's pretty easy to fix so it builds and tests using Java 
>>>>>> 6 -
>>>>>> >> which job is it?
>>>>>> >>
>>>>>> >> > Regards,
>>>>>> >> > Gilles
>>>>>> >> >
>>>>>> >> >
>>>>>> >> >
>>>>>> >> >>
>>>>>> >> >> Gary
>>>>>> >> >>
>>>>>> >> >>
>>>>>> >> >> Regards,
>>>>>> >> >> Gilles
>>>>>> >> >>
>>>>>> >> >>
>>>>>> >> >> On 27 April 2017 at 09:41, Gilles 
>>>>>> <gi...@harfang.homelinux.org>
>>>>>> wrote:
>>>>>> >> >>>
>>>>>> >> >>>
>>>>>> >> >>> On Thu, 27 Apr 2017 14:49:01 +0200, Gilles wrote:
>>>>>> >> >>>>
>>>>>> >> >>>>
>>>>>> >> >>>> Hi.
>>>>>> >> >>>>>
>>>>>> >> >>>>>
>>>>>> >> >>>>> The POM indicates:
>>>>>> >> >>>>>
>>>>>> >> >>>>>     <maven.compiler.source>1.6</maven.compiler.source>
>>>>>> >> >>>>>     <maven.compiler.target>1.6</maven.compiler.target>
>>>>>> >> >>>>>
>>>>>> >> >>>>> but also:
>>>>>> >> >>>>>
>>>>>> >> >>>>>     <commons.release.desc>(requires Java
>>>>>> 7+)</commons.release.desc>
>>>>>> >> >>>>>
>>>>>> >> >>>>> Which is wrong?
>>>>>> >> >>>>>
>>>>>> >> >>>>>
>>>>>> >> >>>>> Also, please not that keeping 1.6 compatibility seems 
>>>>>> to
>>>>>> complicate
>>>>>> >> >>>>
>>>>>> >> >>>> the Jenkins configuration:
>>>>>> >> >>>>   
>>>>>> https://builds.apache.org/view/Apache%20Commons/job/Commons_
>>>>>> >> >>>> Numbers/14/console
>>>>>> >> >>>>
>>>>>> >> >>>> For a new component, shouldn't we just go to Java 8?
>>>>>> >> >>>>
>>>>>> >> >>>>
>>>>>> >> >>>> Gilles
>>>>>> >> >>>>
>>>>>> >> >
>>>>>> >> >
>>>>
>>>>
>>>>
>>


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

Re: [Numbers] Java version?

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

On 30 April 2017 at 15:32, Gilles <gi...@harfang.homelinux.org> wrote:
> On Sun, 30 Apr 2017 14:49:56 +0100, sebb wrote:
>>
>> On 29 April 2017 at 19:10, Gilles <gi...@harfang.homelinux.org> wrote:
>>>
>>> Hi.
>>>
>>> On Sat, 29 Apr 2017 09:46:56 -0400, Raymond DeCampo wrote:
>>>>
>>>>
>>>> Please note I wrote an issue concerning this last week or so.
>>>>
>>>> https://issues.apache.org/jira/browse/NUMBERS-21
>>>>
>>>> I noticed when moving code from [math] to [numbers] that [math] targets
>>>> 7.
>>>
>>>
>>>
>>> As a general rule, this must formally asked on the "dev" ML.
>>> [And, we'll take for granted that if no one raises an objection
>>> within 72 hours, the proposal is accepted.]
>>>
>>>> I had to make some minor downgrades in the code (use of diamond
>>>> operator).
>>>>
>>>> Given that [math] targets Java 7 and [numbers] is based on it, I see no
>>>> reason [numbers] shouldn't target 7 as well.
>>>
>>>
>>>
>>> That's fine with me; however let's note (for the record) that the
>>> last official release of CM (3.6.1) was still Java 5 (five) compatible.
>>> I don't think (TBC) that any of the CM codes intended (as of now) for
>>> inclusion _requires_ Java 7.
>>>
>>> Hence my question about the necessity (seems not) or willingness
>>> (could well be, if just for the comfort of contributors) to upgrade.
>>>
>>> Now, concretely, you could make the "downgrades" and the code is
>>> now Java 6 compatible.
>>> However, as concretely, it is not obvious that we want to loose
>>> more time fiddling with Jenkins to make it perform the build of
>>> code targeted to old Java.
>>
>>
>> IMO it is wrong for Jenkins to dictate the Java compat level of the
>> items it builds.
>
>
> I agree.
>
>> Besides, it is not difficult to do.
>
>
> Then why doesn't INFRA do it when they perform an upgrade that
> breaks what used to work?

Don't ask me, ask them...

> Help welcome, since I must have missed the "easy" part in my
> attempts to fix it...

Which job is failing?

> Gilles
>
>
>>
>>>
>>> Regards,
>>> Gilles
>>>
>>>
>>>
>>>>
>>>>
>>>> On Fri, Apr 28, 2017 at 6:30 PM, sebb <se...@gmail.com> wrote:
>>>>
>>>>> On 28 April 2017 at 16:05, Matt Sicker <bo...@gmail.com> wrote:
>>>>> > If you're going to build for Java 6 using Java 7, then you should
>>>>> > really
>>>>> > use something like <
>>>>> > http://www.mojohaus.org/animal-sniffer/animal-sniffer-maven-plugin/>
>>>>> > to
>>>>> > prevent accidental usage of Java 7.
>>>>>
>>>>> And/Or actually use Java 6 to compile/test, which is pretty easy to do
>>>>> using the -Pjava-1.6 profile.
>>>>>
>>>>> > On 28 April 2017 at 09:51, sebb <se...@gmail.com> wrote:
>>>>> >
>>>>> >> On 28 April 2017 at 13:01, Gilles <gi...@harfang.homelinux.org>
>>>>> >> wrote:
>>>>> >> > Hi.
>>>>> >> >
>>>>> >> > On Thu, 27 Apr 2017 08:42:36 -0700, Gary Gregory wrote:
>>>>> >> >>
>>>>> >> >> On Apr 27, 2017 8:21 AM, "Gilles" <gi...@harfang.homelinux.org>
>>>>> wrote:
>>>>> >> >>
>>>>> >> >> On Thu, 27 Apr 2017 10:10:57 -0500, Matt Sicker wrote:
>>>>> >> >>
>>>>> >> >>> Choosing Java 8 or 7 for a new component depends on the APIs you
>>>>> want
>>>>> >> to
>>>>> >> >>> use for it more so than what's current.
>>>>> >> >>>
>>>>> >> >>
>>>>> >> >> Indeed, the question could be rephrased as: Is there anything to
>>>>> loose
>>>>> >> >> (for a new component) if we allow the larger API of Java 8?
>>>>> >> >>
>>>>> >> >>
>>>>> >> >> I hear people are still using Java
>>>>> >> >>>
>>>>> >> >>> 6, but I doubt those projects are adapting new libraries or
>>>>> upgrading
>>>>> >> any
>>>>> >> >>> of their dependencies as it is...
>>>>> >> >>>
>>>>> >> >>
>>>>> >> >> That has seemed logical to me for a long time...
>>>>> >> >>
>>>>> >> >>
>>>>> >> >> +1
>>>>> >> >>
>>>>> >> >> I say pick the version you think is best.
>>>>> >> >
>>>>> >> >
>>>>> >> > At this point, I can't say exactly.
>>>>> >> > The current code doesn't seem to need Java APIs beyond 6, but
>>>>> >> > other
>>>>> >> > utilities yet to be added might benefit.
>>>>> >> > The only argument for leaving Java 6 is that we have to go through
>>>>> >> > hoops with the Jenkins configuration.
>>>>> >>
>>>>> >> That is not an argument for upping the Java version
>>>>> >>
>>>>> >> > Currently it fails in a way that looks cryptic to me.
>>>>> >>
>>>>> >> That's because Jenkins now requires Java 7 to run Maven jobs, though
>>>>> >> it does not seem to need it for all job types.
>>>>> >>
>>>>> >> > So, unless someone can fix it, I'll bump the dependency to Java 7.
>>>>> >>
>>>>> >> Huh?
>>>>> >> Surely you can just tell Jenkins to use Java 7 to build and test?
>>>>> >> There's no need for the source to be updated as well (there might be
>>>>> >> some Javadoc warnings, I suppose, but those can be fixed without
>>>>> >> compromising Java 6 compat.)
>>>>> >>
>>>>> >> But it's pretty easy to fix so it builds and tests using Java 6 -
>>>>> >> which job is it?
>>>>> >>
>>>>> >> > Regards,
>>>>> >> > Gilles
>>>>> >> >
>>>>> >> >
>>>>> >> >
>>>>> >> >>
>>>>> >> >> Gary
>>>>> >> >>
>>>>> >> >>
>>>>> >> >> Regards,
>>>>> >> >> Gilles
>>>>> >> >>
>>>>> >> >>
>>>>> >> >> On 27 April 2017 at 09:41, Gilles <gi...@harfang.homelinux.org>
>>>>> wrote:
>>>>> >> >>>
>>>>> >> >>>
>>>>> >> >>> On Thu, 27 Apr 2017 14:49:01 +0200, Gilles wrote:
>>>>> >> >>>>
>>>>> >> >>>>
>>>>> >> >>>> Hi.
>>>>> >> >>>>>
>>>>> >> >>>>>
>>>>> >> >>>>> The POM indicates:
>>>>> >> >>>>>
>>>>> >> >>>>>     <maven.compiler.source>1.6</maven.compiler.source>
>>>>> >> >>>>>     <maven.compiler.target>1.6</maven.compiler.target>
>>>>> >> >>>>>
>>>>> >> >>>>> but also:
>>>>> >> >>>>>
>>>>> >> >>>>>     <commons.release.desc>(requires Java
>>>>> 7+)</commons.release.desc>
>>>>> >> >>>>>
>>>>> >> >>>>> Which is wrong?
>>>>> >> >>>>>
>>>>> >> >>>>>
>>>>> >> >>>>> Also, please not that keeping 1.6 compatibility seems to
>>>>> complicate
>>>>> >> >>>>
>>>>> >> >>>> the Jenkins configuration:
>>>>> >> >>>>   https://builds.apache.org/view/Apache%20Commons/job/Commons_
>>>>> >> >>>> Numbers/14/console
>>>>> >> >>>>
>>>>> >> >>>> For a new component, shouldn't we just go to Java 8?
>>>>> >> >>>>
>>>>> >> >>>>
>>>>> >> >>>> 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

Re: [Numbers] Java version?

Posted by Gilles <gi...@harfang.homelinux.org>.

On Sun, 30 Apr 2017 14:49:56 +0100, sebb wrote:
> On 29 April 2017 at 19:10, Gilles <gi...@harfang.homelinux.org> 
> wrote:
>> Hi.
>>
>> On Sat, 29 Apr 2017 09:46:56 -0400, Raymond DeCampo wrote:
>>>
>>> Please note I wrote an issue concerning this last week or so.
>>>
>>> https://issues.apache.org/jira/browse/NUMBERS-21
>>>
>>> I noticed when moving code from [math] to [numbers] that [math] 
>>> targets 7.
>>
>>
>> As a general rule, this must formally asked on the "dev" ML.
>> [And, we'll take for granted that if no one raises an objection
>> within 72 hours, the proposal is accepted.]
>>
>>> I had to make some minor downgrades in the code (use of diamond 
>>> operator).
>>>
>>> Given that [math] targets Java 7 and [numbers] is based on it, I 
>>> see no
>>> reason [numbers] shouldn't target 7 as well.
>>
>>
>> That's fine with me; however let's note (for the record) that the
>> last official release of CM (3.6.1) was still Java 5 (five) 
>> compatible.
>> I don't think (TBC) that any of the CM codes intended (as of now) 
>> for
>> inclusion _requires_ Java 7.
>>
>> Hence my question about the necessity (seems not) or willingness
>> (could well be, if just for the comfort of contributors) to upgrade.
>>
>> Now, concretely, you could make the "downgrades" and the code is
>> now Java 6 compatible.
>> However, as concretely, it is not obvious that we want to loose
>> more time fiddling with Jenkins to make it perform the build of
>> code targeted to old Java.
>
> IMO it is wrong for Jenkins to dictate the Java compat level of the
> items it builds.

I agree.

> Besides, it is not difficult to do.

Then why doesn't INFRA do it when they perform an upgrade that
breaks what used to work?

Help welcome, since I must have missed the "easy" part in my
attempts to fix it...

Gilles

>
>>
>> Regards,
>> Gilles
>>
>>
>>
>>>
>>>
>>> On Fri, Apr 28, 2017 at 6:30 PM, sebb <se...@gmail.com> wrote:
>>>
>>>> On 28 April 2017 at 16:05, Matt Sicker <bo...@gmail.com> wrote:
>>>> > If you're going to build for Java 6 using Java 7, then you 
>>>> should
>>>> > really
>>>> > use something like <
>>>> > 
>>>> http://www.mojohaus.org/animal-sniffer/animal-sniffer-maven-plugin/> 
>>>> to
>>>> > prevent accidental usage of Java 7.
>>>>
>>>> And/Or actually use Java 6 to compile/test, which is pretty easy 
>>>> to do
>>>> using the -Pjava-1.6 profile.
>>>>
>>>> > On 28 April 2017 at 09:51, sebb <se...@gmail.com> wrote:
>>>> >
>>>> >> On 28 April 2017 at 13:01, Gilles 
>>>> <gi...@harfang.homelinux.org>
>>>> >> wrote:
>>>> >> > Hi.
>>>> >> >
>>>> >> > On Thu, 27 Apr 2017 08:42:36 -0700, Gary Gregory wrote:
>>>> >> >>
>>>> >> >> On Apr 27, 2017 8:21 AM, "Gilles" 
>>>> <gi...@harfang.homelinux.org>
>>>> wrote:
>>>> >> >>
>>>> >> >> On Thu, 27 Apr 2017 10:10:57 -0500, Matt Sicker wrote:
>>>> >> >>
>>>> >> >>> Choosing Java 8 or 7 for a new component depends on the 
>>>> APIs you
>>>> want
>>>> >> to
>>>> >> >>> use for it more so than what's current.
>>>> >> >>>
>>>> >> >>
>>>> >> >> Indeed, the question could be rephrased as: Is there 
>>>> anything to
>>>> loose
>>>> >> >> (for a new component) if we allow the larger API of Java 8?
>>>> >> >>
>>>> >> >>
>>>> >> >> I hear people are still using Java
>>>> >> >>>
>>>> >> >>> 6, but I doubt those projects are adapting new libraries or
>>>> upgrading
>>>> >> any
>>>> >> >>> of their dependencies as it is...
>>>> >> >>>
>>>> >> >>
>>>> >> >> That has seemed logical to me for a long time...
>>>> >> >>
>>>> >> >>
>>>> >> >> +1
>>>> >> >>
>>>> >> >> I say pick the version you think is best.
>>>> >> >
>>>> >> >
>>>> >> > At this point, I can't say exactly.
>>>> >> > The current code doesn't seem to need Java APIs beyond 6, but 
>>>> other
>>>> >> > utilities yet to be added might benefit.
>>>> >> > The only argument for leaving Java 6 is that we have to go 
>>>> through
>>>> >> > hoops with the Jenkins configuration.
>>>> >>
>>>> >> That is not an argument for upping the Java version
>>>> >>
>>>> >> > Currently it fails in a way that looks cryptic to me.
>>>> >>
>>>> >> That's because Jenkins now requires Java 7 to run Maven jobs, 
>>>> though
>>>> >> it does not seem to need it for all job types.
>>>> >>
>>>> >> > So, unless someone can fix it, I'll bump the dependency to 
>>>> Java 7.
>>>> >>
>>>> >> Huh?
>>>> >> Surely you can just tell Jenkins to use Java 7 to build and 
>>>> test?
>>>> >> There's no need for the source to be updated as well (there 
>>>> might be
>>>> >> some Javadoc warnings, I suppose, but those can be fixed 
>>>> without
>>>> >> compromising Java 6 compat.)
>>>> >>
>>>> >> But it's pretty easy to fix so it builds and tests using Java 6 
>>>> -
>>>> >> which job is it?
>>>> >>
>>>> >> > Regards,
>>>> >> > Gilles
>>>> >> >
>>>> >> >
>>>> >> >
>>>> >> >>
>>>> >> >> Gary
>>>> >> >>
>>>> >> >>
>>>> >> >> Regards,
>>>> >> >> Gilles
>>>> >> >>
>>>> >> >>
>>>> >> >> On 27 April 2017 at 09:41, Gilles 
>>>> <gi...@harfang.homelinux.org>
>>>> wrote:
>>>> >> >>>
>>>> >> >>>
>>>> >> >>> On Thu, 27 Apr 2017 14:49:01 +0200, Gilles wrote:
>>>> >> >>>>
>>>> >> >>>>
>>>> >> >>>> Hi.
>>>> >> >>>>>
>>>> >> >>>>>
>>>> >> >>>>> The POM indicates:
>>>> >> >>>>>
>>>> >> >>>>>     <maven.compiler.source>1.6</maven.compiler.source>
>>>> >> >>>>>     <maven.compiler.target>1.6</maven.compiler.target>
>>>> >> >>>>>
>>>> >> >>>>> but also:
>>>> >> >>>>>
>>>> >> >>>>>     <commons.release.desc>(requires Java
>>>> 7+)</commons.release.desc>
>>>> >> >>>>>
>>>> >> >>>>> Which is wrong?
>>>> >> >>>>>
>>>> >> >>>>>
>>>> >> >>>>> Also, please not that keeping 1.6 compatibility seems to
>>>> complicate
>>>> >> >>>>
>>>> >> >>>> the Jenkins configuration:
>>>> >> >>>>   
>>>> https://builds.apache.org/view/Apache%20Commons/job/Commons_
>>>> >> >>>> Numbers/14/console
>>>> >> >>>>
>>>> >> >>>> For a new component, shouldn't we just go to Java 8?
>>>> >> >>>>
>>>> >> >>>>
>>>> >> >>>> Gilles
>>>> >> >>>>
>>>> >> >
>>>> >> >
>>
>>


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

Re: [Numbers] Java version?

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

On 29 April 2017 at 19:10, Gilles <gi...@harfang.homelinux.org> wrote:
> Hi.
>
> On Sat, 29 Apr 2017 09:46:56 -0400, Raymond DeCampo wrote:
>>
>> Please note I wrote an issue concerning this last week or so.
>>
>> https://issues.apache.org/jira/browse/NUMBERS-21
>>
>> I noticed when moving code from [math] to [numbers] that [math] targets 7.
>
>
> As a general rule, this must formally asked on the "dev" ML.
> [And, we'll take for granted that if no one raises an objection
> within 72 hours, the proposal is accepted.]
>
>> I had to make some minor downgrades in the code (use of diamond operator).
>>
>> Given that [math] targets Java 7 and [numbers] is based on it, I see no
>> reason [numbers] shouldn't target 7 as well.
>
>
> That's fine with me; however let's note (for the record) that the
> last official release of CM (3.6.1) was still Java 5 (five) compatible.
> I don't think (TBC) that any of the CM codes intended (as of now) for
> inclusion _requires_ Java 7.
>
> Hence my question about the necessity (seems not) or willingness
> (could well be, if just for the comfort of contributors) to upgrade.
>
> Now, concretely, you could make the "downgrades" and the code is
> now Java 6 compatible.
> However, as concretely, it is not obvious that we want to loose
> more time fiddling with Jenkins to make it perform the build of
> code targeted to old Java.

IMO it is wrong for Jenkins to dictate the Java compat level of the
items it builds.
Besides, it is not difficult to do.

>
> Regards,
> Gilles
>
>
>
>>
>>
>> On Fri, Apr 28, 2017 at 6:30 PM, sebb <se...@gmail.com> wrote:
>>
>>> On 28 April 2017 at 16:05, Matt Sicker <bo...@gmail.com> wrote:
>>> > If you're going to build for Java 6 using Java 7, then you should
>>> > really
>>> > use something like <
>>> > http://www.mojohaus.org/animal-sniffer/animal-sniffer-maven-plugin/> to
>>> > prevent accidental usage of Java 7.
>>>
>>> And/Or actually use Java 6 to compile/test, which is pretty easy to do
>>> using the -Pjava-1.6 profile.
>>>
>>> > On 28 April 2017 at 09:51, sebb <se...@gmail.com> wrote:
>>> >
>>> >> On 28 April 2017 at 13:01, Gilles <gi...@harfang.homelinux.org>
>>> >> wrote:
>>> >> > Hi.
>>> >> >
>>> >> > On Thu, 27 Apr 2017 08:42:36 -0700, Gary Gregory wrote:
>>> >> >>
>>> >> >> On Apr 27, 2017 8:21 AM, "Gilles" <gi...@harfang.homelinux.org>
>>> wrote:
>>> >> >>
>>> >> >> On Thu, 27 Apr 2017 10:10:57 -0500, Matt Sicker wrote:
>>> >> >>
>>> >> >>> Choosing Java 8 or 7 for a new component depends on the APIs you
>>> want
>>> >> to
>>> >> >>> use for it more so than what's current.
>>> >> >>>
>>> >> >>
>>> >> >> Indeed, the question could be rephrased as: Is there anything to
>>> loose
>>> >> >> (for a new component) if we allow the larger API of Java 8?
>>> >> >>
>>> >> >>
>>> >> >> I hear people are still using Java
>>> >> >>>
>>> >> >>> 6, but I doubt those projects are adapting new libraries or
>>> upgrading
>>> >> any
>>> >> >>> of their dependencies as it is...
>>> >> >>>
>>> >> >>
>>> >> >> That has seemed logical to me for a long time...
>>> >> >>
>>> >> >>
>>> >> >> +1
>>> >> >>
>>> >> >> I say pick the version you think is best.
>>> >> >
>>> >> >
>>> >> > At this point, I can't say exactly.
>>> >> > The current code doesn't seem to need Java APIs beyond 6, but other
>>> >> > utilities yet to be added might benefit.
>>> >> > The only argument for leaving Java 6 is that we have to go through
>>> >> > hoops with the Jenkins configuration.
>>> >>
>>> >> That is not an argument for upping the Java version
>>> >>
>>> >> > Currently it fails in a way that looks cryptic to me.
>>> >>
>>> >> That's because Jenkins now requires Java 7 to run Maven jobs, though
>>> >> it does not seem to need it for all job types.
>>> >>
>>> >> > So, unless someone can fix it, I'll bump the dependency to Java 7.
>>> >>
>>> >> Huh?
>>> >> Surely you can just tell Jenkins to use Java 7 to build and test?
>>> >> There's no need for the source to be updated as well (there might be
>>> >> some Javadoc warnings, I suppose, but those can be fixed without
>>> >> compromising Java 6 compat.)
>>> >>
>>> >> But it's pretty easy to fix so it builds and tests using Java 6 -
>>> >> which job is it?
>>> >>
>>> >> > Regards,
>>> >> > Gilles
>>> >> >
>>> >> >
>>> >> >
>>> >> >>
>>> >> >> Gary
>>> >> >>
>>> >> >>
>>> >> >> Regards,
>>> >> >> Gilles
>>> >> >>
>>> >> >>
>>> >> >> On 27 April 2017 at 09:41, Gilles <gi...@harfang.homelinux.org>
>>> wrote:
>>> >> >>>
>>> >> >>>
>>> >> >>> On Thu, 27 Apr 2017 14:49:01 +0200, Gilles wrote:
>>> >> >>>>
>>> >> >>>>
>>> >> >>>> Hi.
>>> >> >>>>>
>>> >> >>>>>
>>> >> >>>>> The POM indicates:
>>> >> >>>>>
>>> >> >>>>>     <maven.compiler.source>1.6</maven.compiler.source>
>>> >> >>>>>     <maven.compiler.target>1.6</maven.compiler.target>
>>> >> >>>>>
>>> >> >>>>> but also:
>>> >> >>>>>
>>> >> >>>>>     <commons.release.desc>(requires Java
>>> 7+)</commons.release.desc>
>>> >> >>>>>
>>> >> >>>>> Which is wrong?
>>> >> >>>>>
>>> >> >>>>>
>>> >> >>>>> Also, please not that keeping 1.6 compatibility seems to
>>> complicate
>>> >> >>>>
>>> >> >>>> the Jenkins configuration:
>>> >> >>>>   https://builds.apache.org/view/Apache%20Commons/job/Commons_
>>> >> >>>> Numbers/14/console
>>> >> >>>>
>>> >> >>>> For a new component, shouldn't we just go to Java 8?
>>> >> >>>>
>>> >> >>>>
>>> >> >>>> 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

Re: [Numbers] Java version?

Posted by Gilles <gi...@harfang.homelinux.org>.

Hi.

On Sat, 29 Apr 2017 09:46:56 -0400, Raymond DeCampo wrote:
> Please note I wrote an issue concerning this last week or so.
>
> https://issues.apache.org/jira/browse/NUMBERS-21
>
> I noticed when moving code from [math] to [numbers] that [math] 
> targets 7.

As a general rule, this must formally asked on the "dev" ML.
[And, we'll take for granted that if no one raises an objection
within 72 hours, the proposal is accepted.]

> I had to make some minor downgrades in the code (use of diamond 
> operator).
>
> Given that [math] targets Java 7 and [numbers] is based on it, I see 
> no
> reason [numbers] shouldn't target 7 as well.

That's fine with me; however let's note (for the record) that the
last official release of CM (3.6.1) was still Java 5 (five) compatible.
I don't think (TBC) that any of the CM codes intended (as of now) for
inclusion _requires_ Java 7.

Hence my question about the necessity (seems not) or willingness
(could well be, if just for the comfort of contributors) to upgrade.

Now, concretely, you could make the "downgrades" and the code is
now Java 6 compatible.
However, as concretely, it is not obvious that we want to loose
more time fiddling with Jenkins to make it perform the build of
code targeted to old Java.


Regards,
Gilles


>
>
> On Fri, Apr 28, 2017 at 6:30 PM, sebb <se...@gmail.com> wrote:
>
>> On 28 April 2017 at 16:05, Matt Sicker <bo...@gmail.com> wrote:
>> > If you're going to build for Java 6 using Java 7, then you should 
>> really
>> > use something like <
>> > 
>> http://www.mojohaus.org/animal-sniffer/animal-sniffer-maven-plugin/> 
>> to
>> > prevent accidental usage of Java 7.
>>
>> And/Or actually use Java 6 to compile/test, which is pretty easy to 
>> do
>> using the -Pjava-1.6 profile.
>>
>> > On 28 April 2017 at 09:51, sebb <se...@gmail.com> wrote:
>> >
>> >> On 28 April 2017 at 13:01, Gilles <gi...@harfang.homelinux.org> 
>> wrote:
>> >> > Hi.
>> >> >
>> >> > On Thu, 27 Apr 2017 08:42:36 -0700, Gary Gregory wrote:
>> >> >>
>> >> >> On Apr 27, 2017 8:21 AM, "Gilles" 
>> <gi...@harfang.homelinux.org>
>> wrote:
>> >> >>
>> >> >> On Thu, 27 Apr 2017 10:10:57 -0500, Matt Sicker wrote:
>> >> >>
>> >> >>> Choosing Java 8 or 7 for a new component depends on the APIs 
>> you
>> want
>> >> to
>> >> >>> use for it more so than what's current.
>> >> >>>
>> >> >>
>> >> >> Indeed, the question could be rephrased as: Is there anything 
>> to
>> loose
>> >> >> (for a new component) if we allow the larger API of Java 8?
>> >> >>
>> >> >>
>> >> >> I hear people are still using Java
>> >> >>>
>> >> >>> 6, but I doubt those projects are adapting new libraries or
>> upgrading
>> >> any
>> >> >>> of their dependencies as it is...
>> >> >>>
>> >> >>
>> >> >> That has seemed logical to me for a long time...
>> >> >>
>> >> >>
>> >> >> +1
>> >> >>
>> >> >> I say pick the version you think is best.
>> >> >
>> >> >
>> >> > At this point, I can't say exactly.
>> >> > The current code doesn't seem to need Java APIs beyond 6, but 
>> other
>> >> > utilities yet to be added might benefit.
>> >> > The only argument for leaving Java 6 is that we have to go 
>> through
>> >> > hoops with the Jenkins configuration.
>> >>
>> >> That is not an argument for upping the Java version
>> >>
>> >> > Currently it fails in a way that looks cryptic to me.
>> >>
>> >> That's because Jenkins now requires Java 7 to run Maven jobs, 
>> though
>> >> it does not seem to need it for all job types.
>> >>
>> >> > So, unless someone can fix it, I'll bump the dependency to Java 
>> 7.
>> >>
>> >> Huh?
>> >> Surely you can just tell Jenkins to use Java 7 to build and test?
>> >> There's no need for the source to be updated as well (there might 
>> be
>> >> some Javadoc warnings, I suppose, but those can be fixed without
>> >> compromising Java 6 compat.)
>> >>
>> >> But it's pretty easy to fix so it builds and tests using Java 6 -
>> >> which job is it?
>> >>
>> >> > Regards,
>> >> > Gilles
>> >> >
>> >> >
>> >> >
>> >> >>
>> >> >> Gary
>> >> >>
>> >> >>
>> >> >> Regards,
>> >> >> Gilles
>> >> >>
>> >> >>
>> >> >> On 27 April 2017 at 09:41, Gilles 
>> <gi...@harfang.homelinux.org>
>> wrote:
>> >> >>>
>> >> >>>
>> >> >>> On Thu, 27 Apr 2017 14:49:01 +0200, Gilles wrote:
>> >> >>>>
>> >> >>>>
>> >> >>>> Hi.
>> >> >>>>>
>> >> >>>>>
>> >> >>>>> The POM indicates:
>> >> >>>>>
>> >> >>>>>     <maven.compiler.source>1.6</maven.compiler.source>
>> >> >>>>>     <maven.compiler.target>1.6</maven.compiler.target>
>> >> >>>>>
>> >> >>>>> but also:
>> >> >>>>>
>> >> >>>>>     <commons.release.desc>(requires Java
>> 7+)</commons.release.desc>
>> >> >>>>>
>> >> >>>>> Which is wrong?
>> >> >>>>>
>> >> >>>>>
>> >> >>>>> Also, please not that keeping 1.6 compatibility seems to
>> complicate
>> >> >>>>
>> >> >>>> the Jenkins configuration:
>> >> >>>>   
>> https://builds.apache.org/view/Apache%20Commons/job/Commons_
>> >> >>>> Numbers/14/console
>> >> >>>>
>> >> >>>> For a new component, shouldn't we just go to Java 8?
>> >> >>>>
>> >> >>>>
>> >> >>>> Gilles
>> >> >>>>
>> >> >
>> >> >


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

Re: [Numbers] Java version?

Posted by Gary Gregory <ga...@gmail.com>.

On Apr 29, 2017 6:47 AM, "Raymond DeCampo" <ra...@decampo.org> wrote:

Please note I wrote an issue concerning this last week or so.

https://issues.apache.org/jira/browse/NUMBERS-21

I noticed when moving code from [math] to [numbers] that [math] targets 7.
I had to make some minor downgrades in the code (use of diamond operator).

Given that [math] targets Java 7 and [numbers] is based on it, I see no
reason [numbers] shouldn't target 7 as well.


Sounds fine with me.

Gary



On Fri, Apr 28, 2017 at 6:30 PM, sebb <se...@gmail.com> wrote:

> On 28 April 2017 at 16:05, Matt Sicker <bo...@gmail.com> wrote:
> > If you're going to build for Java 6 using Java 7, then you should really
> > use something like <
> > http://www.mojohaus.org/animal-sniffer/animal-sniffer-maven-plugin/> to
> > prevent accidental usage of Java 7.
>
> And/Or actually use Java 6 to compile/test, which is pretty easy to do
> using the -Pjava-1.6 profile.
>
> > On 28 April 2017 at 09:51, sebb <se...@gmail.com> wrote:
> >
> >> On 28 April 2017 at 13:01, Gilles <gi...@harfang.homelinux.org> wrote:
> >> > Hi.
> >> >
> >> > On Thu, 27 Apr 2017 08:42:36 -0700, Gary Gregory wrote:
> >> >>
> >> >> On Apr 27, 2017 8:21 AM, "Gilles" <gi...@harfang.homelinux.org>
> wrote:
> >> >>
> >> >> On Thu, 27 Apr 2017 10:10:57 -0500, Matt Sicker wrote:
> >> >>
> >> >>> Choosing Java 8 or 7 for a new component depends on the APIs you
> want
> >> to
> >> >>> use for it more so than what's current.
> >> >>>
> >> >>
> >> >> Indeed, the question could be rephrased as: Is there anything to
> loose
> >> >> (for a new component) if we allow the larger API of Java 8?
> >> >>
> >> >>
> >> >> I hear people are still using Java
> >> >>>
> >> >>> 6, but I doubt those projects are adapting new libraries or
> upgrading
> >> any
> >> >>> of their dependencies as it is...
> >> >>>
> >> >>
> >> >> That has seemed logical to me for a long time...
> >> >>
> >> >>
> >> >> +1
> >> >>
> >> >> I say pick the version you think is best.
> >> >
> >> >
> >> > At this point, I can't say exactly.
> >> > The current code doesn't seem to need Java APIs beyond 6, but other
> >> > utilities yet to be added might benefit.
> >> > The only argument for leaving Java 6 is that we have to go through
> >> > hoops with the Jenkins configuration.
> >>
> >> That is not an argument for upping the Java version
> >>
> >> > Currently it fails in a way that looks cryptic to me.
> >>
> >> That's because Jenkins now requires Java 7 to run Maven jobs, though
> >> it does not seem to need it for all job types.
> >>
> >> > So, unless someone can fix it, I'll bump the dependency to Java 7.
> >>
> >> Huh?
> >> Surely you can just tell Jenkins to use Java 7 to build and test?
> >> There's no need for the source to be updated as well (there might be
> >> some Javadoc warnings, I suppose, but those can be fixed without
> >> compromising Java 6 compat.)
> >>
> >> But it's pretty easy to fix so it builds and tests using Java 6 -
> >> which job is it?
> >>
> >> > Regards,
> >> > Gilles
> >> >
> >> >
> >> >
> >> >>
> >> >> Gary
> >> >>
> >> >>
> >> >> Regards,
> >> >> Gilles
> >> >>
> >> >>
> >> >> On 27 April 2017 at 09:41, Gilles <gi...@harfang.homelinux.org>
> wrote:
> >> >>>
> >> >>>
> >> >>> On Thu, 27 Apr 2017 14:49:01 +0200, Gilles wrote:
> >> >>>>
> >> >>>>
> >> >>>> Hi.
> >> >>>>>
> >> >>>>>
> >> >>>>> The POM indicates:
> >> >>>>>
> >> >>>>>     <maven.compiler.source>1.6</maven.compiler.source>
> >> >>>>>     <maven.compiler.target>1.6</maven.compiler.target>
> >> >>>>>
> >> >>>>> but also:
> >> >>>>>
> >> >>>>>     <commons.release.desc>(requires Java
> 7+)</commons.release.desc>
> >> >>>>>
> >> >>>>> Which is wrong?
> >> >>>>>
> >> >>>>>
> >> >>>>> Also, please not that keeping 1.6 compatibility seems to
> complicate
> >> >>>>
> >> >>>> the Jenkins configuration:
> >> >>>>   https://builds.apache.org/view/Apache%20Commons/job/Commons_
> >> >>>> Numbers/14/console
> >> >>>>
> >> >>>> For a new component, shouldn't we just go to Java 8?
> >> >>>>
> >> >>>>
> >> >>>> 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
> >>
> >>
> >
> >
> > --
> > Matt Sicker <bo...@gmail.com>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>

Re: [Numbers] Java version?

Posted by Raymond DeCampo <ra...@decampo.org>.

Please note I wrote an issue concerning this last week or so.

https://issues.apache.org/jira/browse/NUMBERS-21

I noticed when moving code from [math] to [numbers] that [math] targets 7.
I had to make some minor downgrades in the code (use of diamond operator).

Given that [math] targets Java 7 and [numbers] is based on it, I see no
reason [numbers] shouldn't target 7 as well.


On Fri, Apr 28, 2017 at 6:30 PM, sebb <se...@gmail.com> wrote:

> On 28 April 2017 at 16:05, Matt Sicker <bo...@gmail.com> wrote:
> > If you're going to build for Java 6 using Java 7, then you should really
> > use something like <
> > http://www.mojohaus.org/animal-sniffer/animal-sniffer-maven-plugin/> to
> > prevent accidental usage of Java 7.
>
> And/Or actually use Java 6 to compile/test, which is pretty easy to do
> using the -Pjava-1.6 profile.
>
> > On 28 April 2017 at 09:51, sebb <se...@gmail.com> wrote:
> >
> >> On 28 April 2017 at 13:01, Gilles <gi...@harfang.homelinux.org> wrote:
> >> > Hi.
> >> >
> >> > On Thu, 27 Apr 2017 08:42:36 -0700, Gary Gregory wrote:
> >> >>
> >> >> On Apr 27, 2017 8:21 AM, "Gilles" <gi...@harfang.homelinux.org>
> wrote:
> >> >>
> >> >> On Thu, 27 Apr 2017 10:10:57 -0500, Matt Sicker wrote:
> >> >>
> >> >>> Choosing Java 8 or 7 for a new component depends on the APIs you
> want
> >> to
> >> >>> use for it more so than what's current.
> >> >>>
> >> >>
> >> >> Indeed, the question could be rephrased as: Is there anything to
> loose
> >> >> (for a new component) if we allow the larger API of Java 8?
> >> >>
> >> >>
> >> >> I hear people are still using Java
> >> >>>
> >> >>> 6, but I doubt those projects are adapting new libraries or
> upgrading
> >> any
> >> >>> of their dependencies as it is...
> >> >>>
> >> >>
> >> >> That has seemed logical to me for a long time...
> >> >>
> >> >>
> >> >> +1
> >> >>
> >> >> I say pick the version you think is best.
> >> >
> >> >
> >> > At this point, I can't say exactly.
> >> > The current code doesn't seem to need Java APIs beyond 6, but other
> >> > utilities yet to be added might benefit.
> >> > The only argument for leaving Java 6 is that we have to go through
> >> > hoops with the Jenkins configuration.
> >>
> >> That is not an argument for upping the Java version
> >>
> >> > Currently it fails in a way that looks cryptic to me.
> >>
> >> That's because Jenkins now requires Java 7 to run Maven jobs, though
> >> it does not seem to need it for all job types.
> >>
> >> > So, unless someone can fix it, I'll bump the dependency to Java 7.
> >>
> >> Huh?
> >> Surely you can just tell Jenkins to use Java 7 to build and test?
> >> There's no need for the source to be updated as well (there might be
> >> some Javadoc warnings, I suppose, but those can be fixed without
> >> compromising Java 6 compat.)
> >>
> >> But it's pretty easy to fix so it builds and tests using Java 6 -
> >> which job is it?
> >>
> >> > Regards,
> >> > Gilles
> >> >
> >> >
> >> >
> >> >>
> >> >> Gary
> >> >>
> >> >>
> >> >> Regards,
> >> >> Gilles
> >> >>
> >> >>
> >> >> On 27 April 2017 at 09:41, Gilles <gi...@harfang.homelinux.org>
> wrote:
> >> >>>
> >> >>>
> >> >>> On Thu, 27 Apr 2017 14:49:01 +0200, Gilles wrote:
> >> >>>>
> >> >>>>
> >> >>>> Hi.
> >> >>>>>
> >> >>>>>
> >> >>>>> The POM indicates:
> >> >>>>>
> >> >>>>>     <maven.compiler.source>1.6</maven.compiler.source>
> >> >>>>>     <maven.compiler.target>1.6</maven.compiler.target>
> >> >>>>>
> >> >>>>> but also:
> >> >>>>>
> >> >>>>>     <commons.release.desc>(requires Java
> 7+)</commons.release.desc>
> >> >>>>>
> >> >>>>> Which is wrong?
> >> >>>>>
> >> >>>>>
> >> >>>>> Also, please not that keeping 1.6 compatibility seems to
> complicate
> >> >>>>
> >> >>>> the Jenkins configuration:
> >> >>>>   https://builds.apache.org/view/Apache%20Commons/job/Commons_
> >> >>>> Numbers/14/console
> >> >>>>
> >> >>>> For a new component, shouldn't we just go to Java 8?
> >> >>>>
> >> >>>>
> >> >>>> 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
> >>
> >>
> >
> >
> > --
> > Matt Sicker <bo...@gmail.com>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>

Re: [Numbers] Java version?

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

On 28 April 2017 at 16:05, Matt Sicker <bo...@gmail.com> wrote:
> If you're going to build for Java 6 using Java 7, then you should really
> use something like <
> http://www.mojohaus.org/animal-sniffer/animal-sniffer-maven-plugin/> to
> prevent accidental usage of Java 7.

And/Or actually use Java 6 to compile/test, which is pretty easy to do
using the -Pjava-1.6 profile.

> On 28 April 2017 at 09:51, sebb <se...@gmail.com> wrote:
>
>> On 28 April 2017 at 13:01, Gilles <gi...@harfang.homelinux.org> wrote:
>> > Hi.
>> >
>> > On Thu, 27 Apr 2017 08:42:36 -0700, Gary Gregory wrote:
>> >>
>> >> On Apr 27, 2017 8:21 AM, "Gilles" <gi...@harfang.homelinux.org> wrote:
>> >>
>> >> On Thu, 27 Apr 2017 10:10:57 -0500, Matt Sicker wrote:
>> >>
>> >>> Choosing Java 8 or 7 for a new component depends on the APIs you want
>> to
>> >>> use for it more so than what's current.
>> >>>
>> >>
>> >> Indeed, the question could be rephrased as: Is there anything to loose
>> >> (for a new component) if we allow the larger API of Java 8?
>> >>
>> >>
>> >> I hear people are still using Java
>> >>>
>> >>> 6, but I doubt those projects are adapting new libraries or upgrading
>> any
>> >>> of their dependencies as it is...
>> >>>
>> >>
>> >> That has seemed logical to me for a long time...
>> >>
>> >>
>> >> +1
>> >>
>> >> I say pick the version you think is best.
>> >
>> >
>> > At this point, I can't say exactly.
>> > The current code doesn't seem to need Java APIs beyond 6, but other
>> > utilities yet to be added might benefit.
>> > The only argument for leaving Java 6 is that we have to go through
>> > hoops with the Jenkins configuration.
>>
>> That is not an argument for upping the Java version
>>
>> > Currently it fails in a way that looks cryptic to me.
>>
>> That's because Jenkins now requires Java 7 to run Maven jobs, though
>> it does not seem to need it for all job types.
>>
>> > So, unless someone can fix it, I'll bump the dependency to Java 7.
>>
>> Huh?
>> Surely you can just tell Jenkins to use Java 7 to build and test?
>> There's no need for the source to be updated as well (there might be
>> some Javadoc warnings, I suppose, but those can be fixed without
>> compromising Java 6 compat.)
>>
>> But it's pretty easy to fix so it builds and tests using Java 6 -
>> which job is it?
>>
>> > Regards,
>> > Gilles
>> >
>> >
>> >
>> >>
>> >> Gary
>> >>
>> >>
>> >> Regards,
>> >> Gilles
>> >>
>> >>
>> >> On 27 April 2017 at 09:41, Gilles <gi...@harfang.homelinux.org> wrote:
>> >>>
>> >>>
>> >>> On Thu, 27 Apr 2017 14:49:01 +0200, Gilles wrote:
>> >>>>
>> >>>>
>> >>>> Hi.
>> >>>>>
>> >>>>>
>> >>>>> The POM indicates:
>> >>>>>
>> >>>>>     <maven.compiler.source>1.6</maven.compiler.source>
>> >>>>>     <maven.compiler.target>1.6</maven.compiler.target>
>> >>>>>
>> >>>>> but also:
>> >>>>>
>> >>>>>     <commons.release.desc>(requires Java 7+)</commons.release.desc>
>> >>>>>
>> >>>>> Which is wrong?
>> >>>>>
>> >>>>>
>> >>>>> Also, please not that keeping 1.6 compatibility seems to complicate
>> >>>>
>> >>>> the Jenkins configuration:
>> >>>>   https://builds.apache.org/view/Apache%20Commons/job/Commons_
>> >>>> Numbers/14/console
>> >>>>
>> >>>> For a new component, shouldn't we just go to Java 8?
>> >>>>
>> >>>>
>> >>>> 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
>>
>>
>
>
> --
> Matt Sicker <bo...@gmail.com>

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

Re: [Numbers] Java version?

Posted by Matt Sicker <bo...@gmail.com>.

If you're going to build for Java 6 using Java 7, then you should really
use something like <
http://www.mojohaus.org/animal-sniffer/animal-sniffer-maven-plugin/> to
prevent accidental usage of Java 7.

On 28 April 2017 at 09:51, sebb <se...@gmail.com> wrote:

> On 28 April 2017 at 13:01, Gilles <gi...@harfang.homelinux.org> wrote:
> > Hi.
> >
> > On Thu, 27 Apr 2017 08:42:36 -0700, Gary Gregory wrote:
> >>
> >> On Apr 27, 2017 8:21 AM, "Gilles" <gi...@harfang.homelinux.org> wrote:
> >>
> >> On Thu, 27 Apr 2017 10:10:57 -0500, Matt Sicker wrote:
> >>
> >>> Choosing Java 8 or 7 for a new component depends on the APIs you want
> to
> >>> use for it more so than what's current.
> >>>
> >>
> >> Indeed, the question could be rephrased as: Is there anything to loose
> >> (for a new component) if we allow the larger API of Java 8?
> >>
> >>
> >> I hear people are still using Java
> >>>
> >>> 6, but I doubt those projects are adapting new libraries or upgrading
> any
> >>> of their dependencies as it is...
> >>>
> >>
> >> That has seemed logical to me for a long time...
> >>
> >>
> >> +1
> >>
> >> I say pick the version you think is best.
> >
> >
> > At this point, I can't say exactly.
> > The current code doesn't seem to need Java APIs beyond 6, but other
> > utilities yet to be added might benefit.
> > The only argument for leaving Java 6 is that we have to go through
> > hoops with the Jenkins configuration.
>
> That is not an argument for upping the Java version
>
> > Currently it fails in a way that looks cryptic to me.
>
> That's because Jenkins now requires Java 7 to run Maven jobs, though
> it does not seem to need it for all job types.
>
> > So, unless someone can fix it, I'll bump the dependency to Java 7.
>
> Huh?
> Surely you can just tell Jenkins to use Java 7 to build and test?
> There's no need for the source to be updated as well (there might be
> some Javadoc warnings, I suppose, but those can be fixed without
> compromising Java 6 compat.)
>
> But it's pretty easy to fix so it builds and tests using Java 6 -
> which job is it?
>
> > Regards,
> > Gilles
> >
> >
> >
> >>
> >> Gary
> >>
> >>
> >> Regards,
> >> Gilles
> >>
> >>
> >> On 27 April 2017 at 09:41, Gilles <gi...@harfang.homelinux.org> wrote:
> >>>
> >>>
> >>> On Thu, 27 Apr 2017 14:49:01 +0200, Gilles wrote:
> >>>>
> >>>>
> >>>> Hi.
> >>>>>
> >>>>>
> >>>>> The POM indicates:
> >>>>>
> >>>>>     <maven.compiler.source>1.6</maven.compiler.source>
> >>>>>     <maven.compiler.target>1.6</maven.compiler.target>
> >>>>>
> >>>>> but also:
> >>>>>
> >>>>>     <commons.release.desc>(requires Java 7+)</commons.release.desc>
> >>>>>
> >>>>> Which is wrong?
> >>>>>
> >>>>>
> >>>>> Also, please not that keeping 1.6 compatibility seems to complicate
> >>>>
> >>>> the Jenkins configuration:
> >>>>   https://builds.apache.org/view/Apache%20Commons/job/Commons_
> >>>> Numbers/14/console
> >>>>
> >>>> For a new component, shouldn't we just go to Java 8?
> >>>>
> >>>>
> >>>> 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
>
>


-- 
Matt Sicker <bo...@gmail.com>

Re: [Numbers] Java version?

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

On 28 April 2017 at 13:01, Gilles <gi...@harfang.homelinux.org> wrote:
> Hi.
>
> On Thu, 27 Apr 2017 08:42:36 -0700, Gary Gregory wrote:
>>
>> On Apr 27, 2017 8:21 AM, "Gilles" <gi...@harfang.homelinux.org> wrote:
>>
>> On Thu, 27 Apr 2017 10:10:57 -0500, Matt Sicker wrote:
>>
>>> Choosing Java 8 or 7 for a new component depends on the APIs you want to
>>> use for it more so than what's current.
>>>
>>
>> Indeed, the question could be rephrased as: Is there anything to loose
>> (for a new component) if we allow the larger API of Java 8?
>>
>>
>> I hear people are still using Java
>>>
>>> 6, but I doubt those projects are adapting new libraries or upgrading any
>>> of their dependencies as it is...
>>>
>>
>> That has seemed logical to me for a long time...
>>
>>
>> +1
>>
>> I say pick the version you think is best.
>
>
> At this point, I can't say exactly.
> The current code doesn't seem to need Java APIs beyond 6, but other
> utilities yet to be added might benefit.
> The only argument for leaving Java 6 is that we have to go through
> hoops with the Jenkins configuration.

That is not an argument for upping the Java version

> Currently it fails in a way that looks cryptic to me.

That's because Jenkins now requires Java 7 to run Maven jobs, though
it does not seem to need it for all job types.

> So, unless someone can fix it, I'll bump the dependency to Java 7.

Huh?
Surely you can just tell Jenkins to use Java 7 to build and test?
There's no need for the source to be updated as well (there might be
some Javadoc warnings, I suppose, but those can be fixed without
compromising Java 6 compat.)

But it's pretty easy to fix so it builds and tests using Java 6 -
which job is it?

> Regards,
> Gilles
>
>
>
>>
>> Gary
>>
>>
>> Regards,
>> Gilles
>>
>>
>> On 27 April 2017 at 09:41, Gilles <gi...@harfang.homelinux.org> wrote:
>>>
>>>
>>> On Thu, 27 Apr 2017 14:49:01 +0200, Gilles wrote:
>>>>
>>>>
>>>> Hi.
>>>>>
>>>>>
>>>>> The POM indicates:
>>>>>
>>>>>     <maven.compiler.source>1.6</maven.compiler.source>
>>>>>     <maven.compiler.target>1.6</maven.compiler.target>
>>>>>
>>>>> but also:
>>>>>
>>>>>     <commons.release.desc>(requires Java 7+)</commons.release.desc>
>>>>>
>>>>> Which is wrong?
>>>>>
>>>>>
>>>>> Also, please not that keeping 1.6 compatibility seems to complicate
>>>>
>>>> the Jenkins configuration:
>>>>   https://builds.apache.org/view/Apache%20Commons/job/Commons_
>>>> Numbers/14/console
>>>>
>>>> For a new component, shouldn't we just go to Java 8?
>>>>
>>>>
>>>> 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

Re: [Numbers] Java version?

Posted by Gilles <gi...@harfang.homelinux.org>.

Hi.

On Thu, 27 Apr 2017 08:42:36 -0700, Gary Gregory wrote:
> On Apr 27, 2017 8:21 AM, "Gilles" <gi...@harfang.homelinux.org> 
> wrote:
>
> On Thu, 27 Apr 2017 10:10:57 -0500, Matt Sicker wrote:
>
>> Choosing Java 8 or 7 for a new component depends on the APIs you 
>> want to
>> use for it more so than what's current.
>>
>
> Indeed, the question could be rephrased as: Is there anything to 
> loose
> (for a new component) if we allow the larger API of Java 8?
>
>
> I hear people are still using Java
>> 6, but I doubt those projects are adapting new libraries or 
>> upgrading any
>> of their dependencies as it is...
>>
>
> That has seemed logical to me for a long time...
>
>
> +1
>
> I say pick the version you think is best.

At this point, I can't say exactly.
The current code doesn't seem to need Java APIs beyond 6, but other
utilities yet to be added might benefit.
The only argument for leaving Java 6 is that we have to go through
hoops with the Jenkins configuration. Currently it fails in a way
that looks cryptic to me. So, unless someone can fix it, I'll bump
the dependency to Java 7.

Regards,
Gilles


>
> Gary
>
>
> Regards,
> Gilles
>
>
> On 27 April 2017 at 09:41, Gilles <gi...@harfang.homelinux.org> 
> wrote:
>>
>> On Thu, 27 Apr 2017 14:49:01 +0200, Gilles wrote:
>>>
>>> Hi.
>>>>
>>>> The POM indicates:
>>>>
>>>>     <maven.compiler.source>1.6</maven.compiler.source>
>>>>     <maven.compiler.target>1.6</maven.compiler.target>
>>>>
>>>> but also:
>>>>
>>>>     <commons.release.desc>(requires Java 
>>>> 7+)</commons.release.desc>
>>>>
>>>> Which is wrong?
>>>>
>>>>
>>>> Also, please not that keeping 1.6 compatibility seems to 
>>>> complicate
>>> the Jenkins configuration:
>>>   https://builds.apache.org/view/Apache%20Commons/job/Commons_
>>> Numbers/14/console
>>>
>>> For a new component, shouldn't we just go to Java 8?
>>>
>>>
>>> Gilles
>>>


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

Re: [Numbers] Java version?

Posted by Gary Gregory <ga...@gmail.com>.

On Apr 27, 2017 8:21 AM, "Gilles" <gi...@harfang.homelinux.org> wrote:

On Thu, 27 Apr 2017 10:10:57 -0500, Matt Sicker wrote:

> Choosing Java 8 or 7 for a new component depends on the APIs you want to
> use for it more so than what's current.
>

Indeed, the question could be rephrased as: Is there anything to loose
(for a new component) if we allow the larger API of Java 8?


I hear people are still using Java
> 6, but I doubt those projects are adapting new libraries or upgrading any
> of their dependencies as it is...
>

That has seemed logical to me for a long time...


+1

I say pick the version you think is best.

Gary


Regards,
Gilles


On 27 April 2017 at 09:41, Gilles <gi...@harfang.homelinux.org> wrote:
>
> On Thu, 27 Apr 2017 14:49:01 +0200, Gilles wrote:
>>
>> Hi.
>>>
>>> The POM indicates:
>>>
>>>     <maven.compiler.source>1.6</maven.compiler.source>
>>>     <maven.compiler.target>1.6</maven.compiler.target>
>>>
>>> but also:
>>>
>>>     <commons.release.desc>(requires Java 7+)</commons.release.desc>
>>>
>>> Which is wrong?
>>>
>>>
>>> Also, please not that keeping 1.6 compatibility seems to complicate
>> the Jenkins configuration:
>>   https://builds.apache.org/view/Apache%20Commons/job/Commons_
>> Numbers/14/console
>>
>> For a new component, shouldn't we just go to Java 8?
>>
>>
>> Gilles
>>
>>

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

Re: [Numbers] Java version?

Posted by Gilles <gi...@harfang.homelinux.org>.

On Thu, 27 Apr 2017 10:10:57 -0500, Matt Sicker wrote:
> Choosing Java 8 or 7 for a new component depends on the APIs you want 
> to
> use for it more so than what's current.

Indeed, the question could be rephrased as: Is there anything to loose
(for a new component) if we allow the larger API of Java 8?

> I hear people are still using Java
> 6, but I doubt those projects are adapting new libraries or upgrading 
> any
> of their dependencies as it is...

That has seemed logical to me for a long time...

Regards,
Gilles

> On 27 April 2017 at 09:41, Gilles <gi...@harfang.homelinux.org> 
> wrote:
>
>> On Thu, 27 Apr 2017 14:49:01 +0200, Gilles wrote:
>>
>>> Hi.
>>>
>>> The POM indicates:
>>>
>>>     <maven.compiler.source>1.6</maven.compiler.source>
>>>     <maven.compiler.target>1.6</maven.compiler.target>
>>>
>>> but also:
>>>
>>>     <commons.release.desc>(requires Java 7+)</commons.release.desc>
>>>
>>> Which is wrong?
>>>
>>>
>> Also, please not that keeping 1.6 compatibility seems to complicate
>> the Jenkins configuration:
>>   https://builds.apache.org/view/Apache%20Commons/job/Commons_
>> Numbers/14/console
>>
>> For a new component, shouldn't we just go to Java 8?
>>
>>
>> Gilles
>>


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

Re: [Numbers] Java version?

Posted by Matt Sicker <bo...@gmail.com>.

Choosing Java 8 or 7 for a new component depends on the APIs you want to
use for it more so than what's current. I hear people are still using Java
6, but I doubt those projects are adapting new libraries or upgrading any
of their dependencies as it is...

On 27 April 2017 at 09:41, Gilles <gi...@harfang.homelinux.org> wrote:

> On Thu, 27 Apr 2017 14:49:01 +0200, Gilles wrote:
>
>> Hi.
>>
>> The POM indicates:
>>
>>     <maven.compiler.source>1.6</maven.compiler.source>
>>     <maven.compiler.target>1.6</maven.compiler.target>
>>
>> but also:
>>
>>     <commons.release.desc>(requires Java 7+)</commons.release.desc>
>>
>> Which is wrong?
>>
>>
> Also, please not that keeping 1.6 compatibility seems to complicate
> the Jenkins configuration:
>   https://builds.apache.org/view/Apache%20Commons/job/Commons_
> Numbers/14/console
>
> For a new component, shouldn't we just go to Java 8?
>
>
> Gilles
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>


-- 
Matt Sicker <bo...@gmail.com>

Re: [Numbers] Java version?

Posted by Gilles <gi...@harfang.homelinux.org>.

On Thu, 27 Apr 2017 14:49:01 +0200, Gilles wrote:
> Hi.
>
> The POM indicates:
>
>     <maven.compiler.source>1.6</maven.compiler.source>
>     <maven.compiler.target>1.6</maven.compiler.target>
>
> but also:
>
>     <commons.release.desc>(requires Java 7+)</commons.release.desc>
>
> Which is wrong?
>

Also, please not that keeping 1.6 compatibility seems to complicate
the Jenkins configuration:
   
https://builds.apache.org/view/Apache%20Commons/job/Commons_Numbers/14/console

For a new component, shouldn't we just go to Java 8?

Gilles


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