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