On 10/26/06, Jörg Schaible <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
