On Sat, 12 Jul 2014 06:54:46 -0700, Phil Steitz wrote:
On 7/12/14, 6:19 AM, Gilles wrote:
On Fri, 20 Jun 2014 14:52:22 -0700, Phil Steitz wrote:
On 6/20/14, 9:56 AM, Thomas Neidhart wrote:
On 06/20/2014 05:30 PM, Gilles wrote:
On Fri, 20 Jun 2014 16:57:41 +0200, Thomas Neidhart wrote:
On 20 Jun 2014 16:37, "Gilles" <gil...@harfang.homelinux.org>
wrote:
On Fri, 20 Jun 2014 16:18:08 +0200, Thomas Neidhart wrote:
Java 5 is already eol. Anybody still using it is certainly in
maintenance
mode thus adding now a feature that is available in java 6
does not
make
any sense.
This a strong statement in a forum where it has _always_ been
indicated that no post-Java-5 feature could be used.
These two are completely different things.
Not using more recent java features was done in order to still
support
users that are stuck with java 5 but want/have to use commons.
Duplicating java 6 features in 2014 is pointless. What is the
expected
userbase of this feature?
Commons Math itself. And this was the real purpose of
duplicating Java 6:
no user ever asked for those methods in MathArrays. They were
implemented
for the sole reason that CM could not contain calls to methods
not yet
available in Java 5. [See the "pom.xml" of Commons Math.]
New users will certainly have adopted more recent
versions of java and anybody still using java 5 and having a
need for
this
will hopefully have implemented it already in his own codebase.
This is completely unrelated to the issue.
Looking at the original JIRA issue (MATH-1130) it was not clear
that
this is actually related to MATH-1120 and sounded like a user
request to
support this functionality.
As this functionality is used by Commons Math itself the
inclusion is of
course ok.
Regarding the supported versions:
* for the 3.x branch I would stick with java 5
* for the new 4.x branch I would at least switch to java 7
+1
Phil
Do we all agree?
Why not go all the way and switching to Java 8? Any downside?
Are the Java 8 features that we actually need for 4.x? I am not
aware of any. Making the javadoc thingy happy should not force a
dependency on Java 8.
It's to avoid being stuck with an inferred promise that we'll support
version 7 as long as possible (and even longer). :-)
So rather start with the latest and brightest...
There is also the political objective to bring more developers.
New language features could help with that goal; forbidding the new
features could hurt it.
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
