Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Received-SPF: pass (herse.apache.org: domain of niall.pemberton@gmail.com
 designates 66.249.82.225 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=jYgvF7yITSC2QQXNf3fqF63U0Nit/EUg6yb0ryultMqb/+hnVqYQX+Wx8B2S5uVVQ/nYZuXVhrNrPebugZJWjtp3tlIiYjnp5EV2GMtSbFTAlg0x1/nYhJz/5IzL8OD1HYdnSTFzcS0YqjFDqLb7vq49+GRLakJfV+LcnTsyp/g=
Message-ID: <55afdc850610260456s14d3cd17o79f2d1e4a6c080de@mail.gmail.com>
Date: Thu, 26 Oct 2006 12:56:51 +0100
From: "Niall Pemberton" <niall.pemberton@gmail.com>
To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Subject: Re: [collections] Generifying Collections
In-Reply-To: <F0D7281DAB048B438E8F5EC4ECEFBDDC0111D6BD@esmail.elsag.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
References: <F0D7281DAB048B438E8F5EC4ECEFBDDC0111D6BD@esmail.elsag.de>

On 10/26/06, J=F6rg Schaible <Joerg.Schaible@elsag-solutions.com> wrote:
> Hi Niall,
>
> Niall Pemberton wrote on Thursday, October 26, 2006 3:18 AM:
>
> [spip]
>
> >> Beyond this, there are some classes (like TypedList that we
> > don't even want to port as they'd be pointless), plus my
> > desire to create a smaller jar file (time depending), there
> > is ample reason to not worry excessively about backwards
> > compatability. We shoud target about 90% backwards
> > compatible, with the rest being fixing API flaws and issues
> > we have now.
> >
> > Don't you mean 0% backwards compatability - which is what changing
> > the package name results in?
> >
> >> A simple port may appeal conceptually, but its not really viable at
> >> all.
> >
> > I would disagree - if it really is the case that 90% could be ported
> > with backwards compatibility, then it would seem viable IMO.
>
> This is true for an application, but not for a library that is used wide-=
spread. I know a lot of commercial packages depending on some commons jars.=
 See if my app is using a package of vendor a that depends on collections-2=
.0 and vendor B that depedns on collections-4.0. Now I cannot build/run my =
app anymore, since either package of vendor A fails or the one of vendor B.=
 And don't call this hypothetic, we already have such a situation in real l=
ife altzough the lib versions are 95% binary compatible - it was unfortunat=
ely not enough.
>

I think you mis-understand me - I get the issues with backwards
compatibility in libraries (I was around last time Collections caused
problems!). I was suggesting porting the 90% and doing something else
with the rest that couldn't be ported with backwards compatibility
(e.g. deprecate MutliMap and create generified MultiMap2) - with the
result being 100% backwards compatibility.

Niall

> Therefore the whole discussion is not really about introducing generics, =
but of handling incompatibilities between major version changes. And if we =
cannot get the compatibility right anyway, we can also make the next step a=
nd refactor/clean-up API between major versions much better along with incr=
easing the version dependecy on the JDK.
>
> This way a user might have to search and replace the package name in *his=
* library, but then he might be able to compile in 90% of the time and has =
a 100% certainty, that he does not break another app/library his artifact m=
ust coexist with.
>
> > Having said that, its not me thats going to be doing the work, but it
> > does seem valuable to discuss port vs. refactor rather than refactor
> > being a defacto decission and just having an argument on package
> > names.
>
> It is somewhat a general decision for commons.
>
> - J=F6rg

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org