Return-Path: X-Original-To: apmail-commons-dev-archive@www.apache.org Delivered-To: apmail-commons-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 19F51118F6 for ; Fri, 20 Jun 2014 15:31:11 +0000 (UTC) Received: (qmail 61102 invoked by uid 500); 20 Jun 2014 15:31:09 -0000 Delivered-To: apmail-commons-dev-archive@commons.apache.org Received: (qmail 60976 invoked by uid 500); 20 Jun 2014 15:31:09 -0000 Mailing-List: contact dev-help@commons.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "Commons Developers List" Delivered-To: mailing list dev@commons.apache.org Received: (qmail 60964 invoked by uid 99); 20 Jun 2014 15:31:09 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 20 Jun 2014 15:31:09 +0000 X-ASF-Spam-Status: No, hits=-0.7 required=5.0 tests=RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: local policy) Received: from [193.74.71.26] (HELO hel.is.scarlet.be) (193.74.71.26) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 20 Jun 2014 15:31:06 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=scarlet.be; s=scarlet; t=1403278241; bh=GnNhCtfbasVDHAM6uz5Ck/xpc8a6lhpqL1sc4Kkvj0o=; h=MIME-Version:Content-Type:Content-Transfer-Encoding:Date:From:To: Subject:In-Reply-To:References:Message-ID; b=PovEg3etT1OZQMssb053vWa7aBEVNbDuzr+VXutoNY/ka4fLj55aODuCFx/4IHS7W TNbcc9bOZsd0OQ87R8bLAzWL0FrormFCAPxfEp+pZITqxSx8EIBnHwJzBS4YkpXKIP VV96I7oB0svgsKGLnDxULN1YQHAqYbOjyB4W+axU= Received: from webmail.scarlet.be (gresham.is.scarlet.be [193.74.71.215]) by hel.is.scarlet.be (8.14.5/8.14.5) with ESMTP id s5KFUfp0032751 for ; Fri, 20 Jun 2014 17:30:41 +0200 X-Scarlet: d=1403278241 c=193.74.71.215 Received: from pno-astro-26.ulb.ac.be ([164.15.138.26]) via astropc12.ulb.ac.be ([164.15.138.26]) by webmail.scarlet.be with HTTP (HTTP/1.1 POST); Fri, 20 Jun 2014 17:30:41 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Fri, 20 Jun 2014 17:30:41 +0200 From: Gilles To: Subject: Re: [Math] Supported Java versions In-Reply-To: References: <20140620133743.3000123889E1@eris.apache.org> Message-ID: X-Sender: gilles@harfang.homelinux.org User-Agent: Scarlet Webmail X-DCC-scarlet.be-Metrics: hel; whitelist X-Virus-Scanned: clamav-milter 0.98.1-exp at hel X-Virus-Status: Clean X-Virus-Checked: Checked by ClamAV on apache.org On Fri, 20 Jun 2014 16:57:41 +0200, Thomas Neidhart wrote: > On 20 Jun 2014 16:37, "Gilles" 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