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" <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...
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-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
