On Sat, 12 Jul 2014 09:52:12 -0700, Phil Steitz wrote:
On 7/12/14, 9:33 AM, Gilles wrote:
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" <[email protected]>
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...
But that cuts out a big swath of users who are still using Java 7.
What about those who still use Java 6? :-}
It was the same argument that have CM stuck with Java 5 up to now.
And I don't know that it is not the case anymore. Hence the general
question: on what conditions do we want to consider bumping the
Java supported version?
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.
What exactly are the 8 \ 7 features your are referring to? If you
look back at our experience actually developing [math], the last
really useful stuff came in 6 \ 5. If I am missing something, OK
tell me what it is; but if not, I think its better to set the
minimum required jdk to the minimum that does not constrain us.
Note that that does *not* mean developers can't develop, test and
build on 8, 9, ... .
I'm not referring to any particular feature. Only to the general
feature of a language with more features... :-)
I don't understand what you mean by "does not constrain us" and
the "developers" in the above paragraph. Indeed, we (developers of
CM) are constrained if we are not allowed to use new features in CM.
The key factor in deciding minimum JDK level
is what is really useful / needed in the library.
Certainly. But the answer to those questions will vary from one
person to another. My argument was that it is useful to attract
new developers who might be more interested if they are not
forbidden to use the more modern features of the language.
Of course, I don't deny that there are other arguments that go
in the other direction (like users who must run Java 7, or 6 or 5).
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
