commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Ansell <ansell.pe...@gmail.com>
Subject Re: [Numbers] Java version?
Date Sun, 30 Apr 2017 23:08:23 GMT
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 <boards@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 <gilles@harfang.homelinux.org> wrote:
>
>> 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/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 <boards@gmail.com>

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


Mime
View raw message