commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gilles <>
Subject Re: [Net] When should we update net from Java 6 to 7?
Date Sat, 13 Jan 2018 15:00:34 GMT
On Sat, 13 Jan 2018 14:33:39 +0100, Pascal Schumacher wrote:
> Am 13.01.2018 um 01:31 schrieb Gilles:
>> On Fri, 12 Jan 2018 21:51:58 +0100, Pascal Schumacher wrote:
>>> imho we should drop support for java 6 and make every component 
>>> java 7+
>> Why?
> Imho old java versions discourage contributions. Java 7 was released
> in 2011 8 (and Java 8 in 2014), so there is an increasing number of
> developers who never used older versions. Why force volunteers to 
> work
> harder to stay Java 6 compatible when volunteering is supposed to be
> fun?

+1 ;-)

I've argued similarly, for years, that this aspect be taken into
consideration (in *addition* to the other requirements).

Given the monolithic nature of "Commons Math", this aspect was
in *conflict* with some of the other requirements (deemed more
important than the "fun" aspect).

What I'm aiming at is that all the components, large and small,
should seek to be modularized, so that each module can have its
own language level requirement, evolving with the team of
developers who take care, at a given point in time, of the
functionality (within the bounds of its API requirements
towards the other modules).

> Support for Java 6 (and even Java 7) is decreasing everywhere. E.g.
> current maven versions (and maven plugin versions) required Java 7
> (plugin versions supporting Java 6 often do not work on Java 9).
> Current travis VMs do not support build on Java 6...

I also agree on the aspect of "forcing" new users to go away
from outdated tools (as long as there are FLOSS alternatives).

However, the overlap with the previous point is that IMHO, the
source code of a given module should use the same language level
throughout: If wanting to use new features, fine, but then
plan for upgrading *all* the code (a.o. open JIRA tickets to
this end), so that, indeed, new contributors can feel at home
with how to code for that module.


> Just my two cents.
> Cheers,
> Pascal

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message