commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Gregory <GGreg...@seagullsoftware.com>
Subject RE: [io] 2.0 Moving to minimum of JDK 1.5
Date Fri, 08 Feb 2008 16:34:29 GMT
We should get more specific on APIs here and what the problem is. If an algorithm changes,
this is the same problem we have with a new version of any project. Either it's a bug fix
and it is ok to change the behavior or it is not a bug fix and you need to decide if the behavior
must be backward compatible. If it must be, then you need a new method name. Or a new class
I suppose for pluggable classes. This can be dealt with on a case by case basis and is a separate
discussion IMO.

The major differences in API I see is with generics, when we have today a class with possibly
all of:

1) void fooArr(Foo[]);
2) void fooList(List listOfFoos);

3) Bar[] barArr(Bar[]);
4) List barList(List listOfBars);

we want tomorrow, to replace 4) withy:

2) void fooList(List<Foo> listOfFoos);
4) List<Bar> barList(List<Bar> listOfBars);

The question is:  *What is the policy WRT 1, and 3?*

a) Keep the APIs as is.
b) Deprecate
c) Remove

Changing call sites from arrays to list is easy and mechanical but can be an extensive change.
So I would start io2 with a) or b) at worst.

Thank you,
Gary

> -----Original Message-----
> From: jcarman@carmanconsulting.com [mailto:jcarman@carmanconsulting.com]
> On Behalf Of James Carman
> Sent: Friday, February 08, 2008 7:24 AM
> To: Jakarta Commons Developers List
> Subject: Re: [io] 2.0 Moving to minimum of JDK 1.5
>
> On 2/8/08, Jukka Zitting <jukka.zitting@gmail.com> wrote:
> > Hi,
> >
> > On Feb 8, 2008 3:49 PM, James Carman <james@carmanconsulting.com> wrote:
> > > So, you are suggesting having part of a release in the o.a.c.io
> > > package and the other part in the o.a.c.io2?
> >
> > No. I'd keep everything in o.a.c.io.
> >
> > If there's a class or interface, say o.a.c.io.SomeClass, that needs to
> > be changed extensively to match "Java 5 style", then I'd name the
> > modified version o.a.c.io.SomeClass2 (or something better if
> > possible).
> >
>
> I don't know about that.  Then, we could potentially have classes like
> SomeClass, SomeClass2, SomeClass3, etc. running around.  Also, it
> wouldn't be as easy to upgrade to a new version.  If it were done the
> other way, folks could just do a find/replace on the package name in
> their code and be done.
>
> On the other hand, it does allow you to introduce new incompatible
> logic without requiring a new major release.  Hopefully folks wouldn't
> abuse that.
>
>
> > I assume such cases to be the exception rather than the rule, so I
> > don't see the point in renaming the entire package.
> >
> > Java 5 is just an enabler of new features (generics, etc.), it doesn't
> > magically make existing APIs obsolete. Sure, you probably want to
> > adjust collection types, but that's just like any other API change
> > request.
> >
> > BR,
> >
> > Jukka Zitting
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org


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


Mime
View raw message