[prev in list] [next in list] [prev in thread] [next in thread]
List: jakarta-commons-dev
Subject: Re: [Numbers] Java =?UTF-8?Q?version=3F?=
From: Gilles <gilles () harfang ! homelinux ! org>
Date: 2017-04-30 14:55:56
Message-ID: 720b81e56113cd047167f01df894b5a2 () scarlet ! be
[Download RAW message or body]
On Sun, 30 Apr 2017 15:39:20 +0100, sebb wrote:
> On 30 April 2017 at 15:32, Gilles <gilles@harfang.homelinux.org>
> wrote:
>> On Sun, 30 Apr 2017 14:49:56 +0100, sebb wrote:
>>>
>>> On 29 April 2017 at 19:10, Gilles <gilles@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 <sebbaz@gmail.com> wrote:
>>>>>
>>>>>> On 28 April 2017 at 16:05, Matt Sicker <boards@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 <sebbaz@gmail.com> wrote:
>>>>>> >
>>>>>> >> On 28 April 2017 at 13:01, Gilles
>>>>>> <gilles@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/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
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic