commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Carman" <ja...@carmanconsulting.com>
Subject Re: [collections] Generifying Collections
Date Mon, 23 Oct 2006 18:14:50 GMT
Tomcat has been able to do this without any real problems.  Why can't we
just keep the Commons Collections name (and packages, etc.), but just use
the version numbers to keep it straight?  Tomcat 5.5.x requires JDK5.
Couldn't we just say that Commons Collections 4.x (and beyond) requires
JDK5?  That way, for those folks who want to upgrade, it's not very tough.
For the most part, the classes/methods will have the same names.

On 10/23/06, Jörg Schaible <Joerg.Schaible@elsag-solutions.com> wrote:
>
> Hi Stephen and Henri,
>
> Stephen Colebourne wrote on Saturday, October 21, 2006 5:20 PM:
>
> > Henri Yandell wrote:
> >> Why not just start a branch within Collections?
> >>
> >> I don't see why this is a new component, are we going to be advising
> >> people to use Collections 3.x on JDK 1.5+ for any reasons other than
> >> legacy or instability of our generified version?
> >>
> >> My view is to make a collections-generics branch in collections with
> >> a view to it being Collections 4.0.
> >
> > Because commons isn't like other OSS projects. We can't go around
> > changing our APIs freely, even between major versions. Its a
> > simple case
> > of us being at the bottom of the stack of jars. If we do
> > change an API,
> > any API then jar hell ensues because higher OSS projects will
> > clash on
> > their required versions of [collections].
> >
> > Thus, it has to be a new package, and this is best thought of
> > as a new
> > component.
>
> It is also about branding. Collections is a well-known name in the
> community. Think of three years from now. If we declare collections 4.xneeds JDK
> 1.5+ now, in 3 years nobody will rermember, that the older versions did
> support JDK 1.3. But the name for collections still persist. That's the
> political reason, not to change the name.
>
> > (Compare this with the JDK where they had to jump through ridiculous
> > hoops to make generics fully backwards-compatible, and created a
> > half-arsed mess in the process...)
>
> This is the real problem. We must use a different namespace for the Java
> package itself. A lot of stuff depends on c-c (
> http://www.mavenregistry.com/search/artifact/19973 +
> http://www.mavenregistry.com/search/depended_upon_artifacts, quite
> impressive) and even in 3 years there will be stuff available that still
> depends on those old versions.
>
> A new package name solves the problem of coexistence as long as the jar
> name contains the version (e.g. commons-collection-3.1 &
> commons-collection-4.2) but it creates new problems for e.g. Maven, that
> cannot handle two (binary distinct) versions at the same time.
>
> So there are three points to decide:
> - does a new package name imply a different Jakarta Commons project?
> - shall we give up existing brands (it means in the end the establishment
> of a new brand for all commons projects)?
> - if we keep the project name, do we have to accept the inevitable limits
> of popular tools such as Maven?
>
> - Jörg
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message