You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Thomas Neidhart <th...@gmail.com> on 2014/06/20 16:18:08 UTC
Re: svn commit: r1604172 - in /commons/proper/math/trunk/src:
main/java/org/apache/commons/math3/util/MathArrays.java test/java/org/apache/commons/math3/util/MathArraysTest.java
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.
On 20 Jun 2014 15:38, <er...@apache.org> wrote:
> Author: erans
> Date: Fri Jun 20 13:37:42 2014
> New Revision: 1604172
>
> URL: http://svn.apache.org/r1604172
> Log:
> MATH-1130
> Method "copyOfRange" (available as of Java 6 in "java.util.Arrays").
>
> Modified:
>
> commons/proper/math/trunk/src/main/java/org/apache/commons/math3/util/MathArrays.java
>
> commons/proper/math/trunk/src/test/java/org/apache/commons/math3/util/MathArraysTest.java
>
> Modified:
> commons/proper/math/trunk/src/main/java/org/apache/commons/math3/util/MathArrays.java
> URL:
> http://svn.apache.org/viewvc/commons/proper/math/trunk/src/main/java/org/apache/commons/math3/util/MathArrays.java?rev=1604172&r1=1604171&r2=1604172&view=diff
>
> ==============================================================================
> ---
> commons/proper/math/trunk/src/main/java/org/apache/commons/math3/util/MathArrays.java
> (original)
> +++
> commons/proper/math/trunk/src/main/java/org/apache/commons/math3/util/MathArrays.java
> Fri Jun 20 13:37:42 2014
> @@ -799,6 +799,21 @@ public class MathArrays {
> }
>
> /**
> + * Creates a copy of the {@code source} array.
> + *
> + * @param source Array to be copied.
> + * @param from Initial index of the range to be copied, inclusive.
> + * @param to Final index of the range to be copied, exclusive. (This
> index may lie outside the array.)
> + * @return the copied array.
> + */
> + public static double[] copyOfRange(double[] source, int from, int to)
> {
> + final int len = to - from;
> + final double[] output = new double[len];
> + System.arraycopy(source, from, output, 0, FastMath.min(len,
> source.length - from));
> + return output;
> + }
> +
> + /**
> * Compute a linear combination accurately.
> * This method computes the sum of the products
> * <code>a<sub>i</sub> b<sub>i</sub></code> to high accuracy.
>
> Modified:
> commons/proper/math/trunk/src/test/java/org/apache/commons/math3/util/MathArraysTest.java
> URL:
> http://svn.apache.org/viewvc/commons/proper/math/trunk/src/test/java/org/apache/commons/math3/util/MathArraysTest.java?rev=1604172&r1=1604171&r2=1604172&view=diff
>
> ==============================================================================
> ---
> commons/proper/math/trunk/src/test/java/org/apache/commons/math3/util/MathArraysTest.java
> (original)
> +++
> commons/proper/math/trunk/src/test/java/org/apache/commons/math3/util/MathArraysTest.java
> Fri Jun 20 13:37:42 2014
> @@ -588,6 +588,29 @@ public class MathArraysTest {
> }
> }
>
> + @Test
> + public void testCopyOfRange() {
> + final double[] source = { Double.NEGATIVE_INFINITY,
> + -Double.MAX_VALUE,
> + -1, 0,
> + Double.MIN_VALUE,
> + FastMath.ulp(1d),
> + 1, 3, 113, 4769,
> + Double.MAX_VALUE,
> + Double.POSITIVE_INFINITY };
> + final int from = 3;
> + final int to = source.length + 14;
> + final double[] dest = MathArrays.copyOfRange(source, from, to);
> +
> + Assert.assertEquals(dest.length, to - from);
> + for (int i = from; i < source.length; i++) {
> + Assert.assertEquals(source[i], dest[i - from], 0);
> + }
> + for (int i = source.length; i < dest.length; i++) {
> + Assert.assertEquals(0, dest[i - from], 0);
> + }
> + }
> +
> // MATH-1005
> @Test
> public void testLinearCombinationWithSingleElementArray() {
>
>
>
Re: [Math] Supported Java versions
Posted by Phil Steitz <ph...@gmail.com>.
On 7/13/14, 4:31 PM, Gilles wrote:
> 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" <gi...@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...
>>
>> 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.
I guess what I mean is that unless and until someone - a current or
new contributor - steps up with a development use case that shows
that not being able to use some Java 8 feature constrains what they
want to do / how they want to do it, there is no reason to create
the dependency and force all users of 4.x to upgrade to J8 to use
it. Maybe someone thinks that lambda expressions will enable us to
reach the end of history in refactoring the optimization package
;) Maybe others think the new features are half-baked. Maybe
others would rather focus on fixing algorithms ;) We should at least
have the discussion before leaving what likely amounts to the
majority of Java users behind (anybody have any stats on J8 adoption??)
Phil
>
>> 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: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Math] Supported Java versions
Posted by Gilles <gi...@harfang.homelinux.org>.
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" <gi...@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...
>
> 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: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Math] Supported Java versions
Posted by Phil Steitz <ph...@gmail.com>.
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" <gi...@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...
But that cuts out a big swath of users who are still using Java 7.
>
> 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, ... . The key factor in deciding minimum JDK level
is what is really useful / needed in the library.
Phil
>
> Gilles
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Math] Supported Java versions
Posted by Gilles <gi...@harfang.homelinux.org>.
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" <gi...@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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Math] Supported Java versions
Posted by Phil Steitz <ph...@gmail.com>.
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" <gi...@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.
Phil
>
>
> Gilles
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Math] Supported Java versions
Posted by Gilles <gi...@harfang.homelinux.org>.
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" <gi...@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?
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Math] Supported Java versions
Posted by Phil Steitz <ph...@gmail.com>.
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" <gi...@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
>
> Thomas
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Math] Supported Java versions
Posted by Thomas Neidhart <th...@gmail.com>.
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" <gi...@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
Thomas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Math] Supported Java versions
Posted by venkatesha murthy <ve...@gmail.com>.
On Fri, Jun 20, 2014 at 9:00 PM, Gilles <gi...@harfang.homelinux.org> wrote:
> On Fri, 20 Jun 2014 16:57:41 +0200, Thomas Neidhart wrote:
>>
>> On 20 Jun 2014 16:37, "Gilles" <gi...@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.
>
>>>
>>> The right question, to be asked again (in case the answer will be
>>> different from all the other times) is: Is Commons Math still to
>>> support Java 5 ?
>>>
>>> If not, to which version do we switch to? 6, 7, 8?
I think JDK 7 may be the way to go ; since per
http://www.oracle.com/technetwork/java/eol-135779.html ; even JDK 6
has stopped public updates since last year.
>>
>>
>> Thats another question to be asked, but orthogonal to the above.
>
>
> No. The question is really: In Commons Math, can we call JDK's features
> that are post-Java-5?
> The answer has up to now been "No".
>
> If it becomes "yes", there are several CM methods that can be deprecated,
> and whose implementation can be right-away delegated to their JDK equivalent
> (in particular the "copyOf" family in "MathArrays").
>
> If it is still "No", for the reason you gave yourself above (users stuck
> with
> Java 5), then how is "copyOfRange" any different from all the other methods
> with a similar purpose (which is: prepare for switching to higher Java
> version)?
>
>
> Gilles
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Math] Supported Java versions
Posted by Gilles <gi...@harfang.homelinux.org>.
On Fri, 20 Jun 2014 16:57:41 +0200, Thomas Neidhart wrote:
> On 20 Jun 2014 16:37, "Gilles" <gi...@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.
>>
>> The right question, to be asked again (in case the answer will be
>> different from all the other times) is: Is Commons Math still to
>> support Java 5 ?
>>
>> If not, to which version do we switch to? 6, 7, 8?
>
> Thats another question to be asked, but orthogonal to the above.
No. The question is really: In Commons Math, can we call JDK's features
that are post-Java-5?
The answer has up to now been "No".
If it becomes "yes", there are several CM methods that can be
deprecated,
and whose implementation can be right-away delegated to their JDK
equivalent
(in particular the "copyOf" family in "MathArrays").
If it is still "No", for the reason you gave yourself above (users
stuck with
Java 5), then how is "copyOfRange" any different from all the other
methods
with a similar purpose (which is: prepare for switching to higher Java
version)?
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Math] Supported Java versions (Was: svn commit: r1604172 - ...)
Posted by Thomas Neidhart <th...@gmail.com>.
On 20 Jun 2014 16:37, "Gilles" <gi...@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? 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.
>
> The right question, to be asked again (in case the answer will be
> different from all the other times) is: Is Commons Math still to
> support Java 5 ?
>
> If not, to which version do we switch to? 6, 7, 8?
Thats another question to be asked, but orthogonal to the above.
>
> Gilles
>
>> > [...]
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
[Math] Supported Java versions (Was: svn commit: r1604172 - ...)
Posted by Gilles <gi...@harfang.homelinux.org>.
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.
The right question, to be asked again (in case the answer will be
different from all the other times) is: Is Commons Math still to
support Java 5 ?
If not, to which version do we switch to? 6, 7, 8?
Gilles
> > [...]
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org