commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Morgan Delagrange <>
Subject Re: [Pattern] Sandbox proposal, affects [Collections][Util] [was: Re: Core architecture [was: Commons architecture]]
Date Tue, 25 Jun 2002 23:42:48 GMT

--- Stephen Colebourne <>
> From: "Morgan Delagrange" <>
> > -1 on moving the comparators package out of
> > Collections.  It clearly falls in that domain;
> that's
> > where users would expect to find them.
> Then why are there comparators in the Util project?

They are there because they were immature or otherwise
unsuitable for release.  All Comparators that we
decided were ready for release were moved from Util to
Collections.  Util is an unreleased sandbox component.

> Yes, there is a tendency
> to think of comparators as being collections
> focussed, but they're not. A
> Comparator can be used to compare two objects
> irrespective of whether they
> are in a collection. Therefore they are not in the
> domain of collections
> exclusively.

They're more appropriate in Collections than in

> >  Also, all of
> > those comparators are released classes.
> Fine, so they get deprecated

-1 to cavalier deprecation.

> > Actually I'm suspicious of a "pattern" package. 
> It
> > seems way, way too broad:
> >
> >    "The standard Java libraries provides for
> >     some very common design patterns -
> >     Comparator/Comparable, EventListener,
> >     Observer/Observable, Cloneable and Runnable
> >     However, other generic pattern concepts are
> >     not supported. The <em>Pattern</em>
> >     Package provides these extra pattern
> >     interfaces. It also provides reference
> >     implementations and utilities for the
> >     additional interfaces and those
> >     interfaces in Java."
> >
> > "[G]eneric pattern concepts" sounds like a recipe
> for
> > hodge-podge.  If you want to try out patterns,
> which
> > could be interesting, you definitely want smaller
> more
> > focused packages (e.g. a package devoted to XML
> > patterns).
> I am open to alternative, tighter, wording, but I
> don't want lots of tiny
> projects, each with 2 classes. 

It's not the wording that I object to, it's the idea
of a project for "generic patterns" of all shapes and

> XML patterns should
> for example be excluded.
> XML is a specific technology, not something generic.
> What the proposal
> should make clear is that these patterns are ones
> that could probably sit in
> java.lang or java.util happily.

Or you could create a series of more focused
components.  Maybe you'll be able to provide them as a
single downloadable distribution as well as individual
downloads, but I think you're better off with a more
discrete strategy.

Take it or leave it.  You're welcome to fire up a
sandbox component and see how it shakes out (-1 to
moving comparators from Collections though).  I think
you'd be better off giving your sandbox some time to
percolate, rather than pushing for a quick release.

> Stephen

- Morgan

Morgan Delagrange

Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup

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

View raw message