commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simon Kitching <>
Subject Re: [io] 2.0 Moving to minimum of JDK 1.5
Date Wed, 06 Feb 2008 16:12:33 GMT
---- Niall Pemberton <> schrieb:
> On Feb 6, 2008 1:44 PM, Simon Kitching <> wrote:
> > ---- Stephen Colebourne <> schrieb:
> > > Deprecation is useful when a method has been
> > > implemented incorrectly, and we want to push users
> > > to a replacement, or for similar issues. Removing deprecated
> > > classes/methods should be considered in a major version change,
> > > but even there we should question what the gain is. Having a
> > > 'nice and clean' no deprecations API release isn't sufficient a
> > > reason. We must always put the convenience of our users ahead of
> > > our natural refactoring and coding instincts.
> >
> > +1
> >
> > If a deprecated method is blocking significant improvement of the product, then
ok remove it. But just to "clean up" is not really a good enough excuse.
> I don't mind the deprecations staying for IO 2.x - just thought that
> if there was going to be a package rename for JDK 1.5, then may as
> well clean up the deprecations as well. If, because of generic erasure
> IO 2.x isn't incompatible (except for the requirement for a higher JDK
> version) then how about retaining the current package name?

*If* the package name changes, then the deprecated methods should definitely go, as there
is no way removing them can break existing users and lead to jar hell.

Regarding a new java5-enabled io that is backwards-compatible: well, if the existing API is
sound, and can be adequately genericised without breaking backwards compatibility, then keeping
the old package-name seems sensible. Adding new methods is not a problem, as that won't break
existing users. Only if the existing methods need to be refactored would a package-name change
make sense.

Alternatively, where existing apis cannot be made generic without breaking existing users,
maybe the new methods could be added within a different package of the existing
library, leaving the old ones alone? Then there is still one jar that everyone can use. Yes
there would be a bit of duplicated code in it, but that's still easier to manage than maintaining
1.x and 2.x branches. 


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message