commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Niall Pemberton" <niall.pember...@gmail.com>
Subject Re: [collections] Generifying Collections
Date Thu, 26 Oct 2006 11:56:51 GMT
On 10/26/06, Jörg 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 life altzough
the lib versions are 95% binary compatible - it was unfortunately 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 and refactor/clean-up API between major versions much
better along with increasing 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 must 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örg

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


Mime
View raw message