From dev-return-136709-apmail-commons-dev-archive=commons.apache.org@commons.apache.org Wed Jul 4 14:01:11 2012
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 DD44999A8
for ; Wed, 4 Jul 2012 14:01:10 +0000 (UTC)
Received: (qmail 35582 invoked by uid 500); 4 Jul 2012 14:01:09 -0000
Delivered-To: apmail-commons-dev-archive@commons.apache.org
Received: (qmail 35401 invoked by uid 500); 4 Jul 2012 14:01:08 -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 35374 invoked by uid 99); 4 Jul 2012 14:01:07 -0000
Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230)
by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 04 Jul 2012 14:01:07 +0000
X-ASF-Spam-Status: No, hits=-0.0 required=5.0
tests=SPF_HELO_PASS,SPF_PASS
X-Spam-Check-By: apache.org
Received-SPF: pass (nike.apache.org: domain of jak-commons-dev@m.gmane.org designates 80.91.229.3 as permitted sender)
Received: from [80.91.229.3] (HELO plane.gmane.org) (80.91.229.3)
by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 04 Jul 2012 14:00:59 +0000
Received: from list by plane.gmane.org with local (Exim 4.69)
(envelope-from )
id 1SmQ8D-0007X2-Eo
for dev@commons.apache.org; Wed, 04 Jul 2012 16:00:37 +0200
Received: from mail.scalaris.com ([62.154.225.82])
by main.gmane.org with esmtp (Gmexim 0.1 (Debian))
id 1AlnuQ-0007hv-00
for ; Wed, 04 Jul 2012 16:00:37 +0200
Received: from Joerg.Schaible by mail.scalaris.com with local (Gmexim 0.1 (Debian))
id 1AlnuQ-0007hv-00
for ; Wed, 04 Jul 2012 16:00:37 +0200
X-Injected-Via-Gmane: http://gmane.org/
To: dev@commons.apache.org
From: =?UTF-8?B?SsO2cmc=?= Schaible
Subject: Re: [collections] Cleanup of trunk
Date: Wed, 04 Jul 2012 16:00:24 +0200
Organization: Scalaris AG
Lines: 61
Message-ID:
References: <4FE6DDBA.4000803@gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8Bit
X-Complaints-To: usenet@dough.gmane.org
X-Gmane-NNTP-Posting-Host: mail.scalaris.com
User-Agent: KNode/4.8.3
Hi Stephen,
Stephen Colebourne wrote:
> To clarify what I've said before, there are two user requirements here;
> - adding generics to the last release while maintaining compatibility
> - rethinking some APIs to get the best design features for Java 5+
> (non-compatible)
>
> ATM, no one is working on the first that I can see, yet that is what
> the existing user base actually wants. The users won't be able to
> upgrade to a non-compatible release, due to the fact that other open
> source projects depend on the current release.
Even the current code base is already beyond this goal. Some methods have
already be renamed and it is no longer a drop in replacement.
> Thus, for me, any non-compatible release is effectively a new project.
> It would be clearer to rename the project and start again at version
> 1.0 for the non-compatible codebase. Maybe [collectionsplus]. A lot
> clearer than what happened with [lang3].
Actually I was very satisfied with the lang3 approach. In our own projects
we have been switched completely, normally just by exchanging the impoert
statement. Nevertheless, we did not get rid of lang itself, but it is
introduced by 3rd party stuff and will hopefully vanish completely over
time.
> Bear in mind that [lang] (version 2) and [collections] are number 6
> and 7 on the most downloaded artifacts list
> http://search.maven.org/#stats
Yeah, but what's new about this? With lang3, lang did not vanish and all the
projects that use it, do not switch over night. I'd be really interested,
how the number of downloads of lang and lang3 changed over time since lang3
was released. Actually we already have now in the meanwhile 3rd party stuff
that depends on lang3 - a clear indication for me.
> However, the big issue here is that the whole library will need
> rewriting for JDK 8 due to lambdas. So what does a non-compatible
> release now actually accomplish?
So wait for another 2 years for collections?
> Well, since I'm not being active, I'm not going to stop people. But I
> am trying to speak up for the users, who just want a compatible
> bug-fixed, generified version (even if it can't be fully generifed,
> some generics are better than none).
>
> Note that none of this is about Java 5 vs 6. Its about compatibility
> and what users actually want (remember the maven download stats!!).
Actually I doubt that you can argument here with the download stats. It is
like arguing that all people driving a heavy used road will rather have a
better pavement instead of one on a new trail with an additional lane.
If somebody really wants to create a generified binary compatible
collections 3.x, it can be done on the branch and released as 3.3.
Personally I am just not interested in making it. ;-)
- Jörg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org