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 <gil...@harfang.homelinux.org> wrote:

> On Sun, 30 Apr 2017 15:39:20 +0100, sebb wrote:
>
>> On 30 April 2017 at 15:32, Gilles <gil...@harfang.homelinux.org> wrote:
>>
>>> On Sun, 30 Apr 2017 14:49:56 +0100, sebb wrote:
>>>
>>>>
>>>> On 29 April 2017 at 19:10, Gilles <gil...@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 <seb...@gmail.com> wrote:
>>>>>>
>>>>>> On 28 April 2017 at 16:05, Matt Sicker <boa...@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 <seb...@gmail.com> wrote:
>>>>>>> >
>>>>>>> >> On 28 April 2017 at 13:01, Gilles <gil...@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" <
>>>>>>> gil...@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 <
>>>>>>> gil...@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-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>


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

Reply via email to