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 <boa...@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 <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>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
