commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Henri Yandell <bay...@generationjava.com>
Subject Re: [Lang][Util] Merge lang and util ? [was Re: [Lang] Add Factory and Identifier to Lang]
Date Sat, 22 Jun 2002 17:30:10 GMT

-1

The reason Util is eternally in the sandbox is because all manner of
oddities get dumped into it. It's really Misc. That makes it very hard to
manage and take to 1.0. In fact the common way to go from Util to a 1.0
has so far been to break out of Util.

Lang is not eternally in the sandbox as it's only been around since the
start of the year. Projects are already linking to the sandboxed version
of Lang and I think that once it goes into 1.0 there will be a high amount
of usage.

Taking Lang/IO/others out of Util was done so that they could manageably
go to 1.0's. Util was a big mess when everything was unified.

I do think that a distribution of Apache-Jakarta-Commons-Core should be
deployable at some point, containing the net/io/collections/lang/other
projects, but not that we should declare a new core project which would
merely be a renaming of the old messy util.

The current development methodology seems to be one of making it hard for
a component-set to get into another project. Is this bad? For example.
Lang goes to 1.0. Reflect and ThreadContext live in sandbox. When reflect
goes to 1.0, it is migrated into Lang [after a heated discussion and many
arguments]. Sandbox keeps a 'not in my backyard' attitude, then migrations
to Commons are where those decisions are re-evaluated.

Hen

On Sat, 22 Jun 2002, Stephen Colebourne wrote:

> Another thread has indicated that Lang and Util seem to be eternally in the
> sandbox, and never make it to commons proper. I suggest the reason is at
> least in part that they are too small to stand alone.
>
> Avalon and collections threads have indicated that there are lots of ideas
> for *very* low level code. But noone quite wants to commit to whether they
> are lang, util or have to live in their own small component.
> (Predicate/Transform/Closure/Factory/Identifiable/Nameable/Comparators/Refle
> ct/Thread/ etc.)
>
> I suggest the answer is to merge Lang and Util into one. A component with
> sufficient momentum, with sufficient developers, with sufficient useful
> classes that it becomes *essential* to other commons projects to use it. A
> component that can actually make it to commons proper. If a new name is
> needed fine - but this distinction between lang and util seems very
> artificial (its blurred in Java too).
>
> I believe that most if not all commons projects _should_ be using a common
> core, but I am unconvinced that if Lang and Util were promoted today that
> _any_ commons project would actually choose to link to them. For me, this is
> not because of lack of tests or lack of useful code, but because of lack of
> 'essentialness'.
>
> My proposal would read along the lines of:
> "xxx is a component to provide essential utility code useful to all
> projects. Specific utilities are provided for the classes in java.lang and
> java.util, with the exception of collections. Also present is functionality
> that ideally should be present in the JDK."
>
> One thread used the term 'Organic' for the growth of commons. Is it time for
> a little pruning? Opinions?
>
> Stephen,
> getting worried that all he's doing is proposing refactoring, but feeling
> compelled to do so ;-)
>
> ----- Original Message -----
> From: "Henri Yandell" <bayard@generationjava.com>
> To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
> Sent: Saturday, June 22, 2002 5:51 PM
> Subject: Re: [Lang] Add Factory and Identifier to Lang
>
>
> >
> > -1. These aren't Lang things. They seem to me to be more a question of
> > making a common set of interfaces for patterns.
> >
> > A package I have for myself is com.xx.patterns. Then inside that I have a
> > Null interface for showing if something implements the Null pattern, and a
> > set of Registrys for things that implement the Registry pattern [okay, not
> > really the right name for a pattern, is a name my colleagues and I used
> > for Factories with modifiable state].
> >
> > Lang is for things that map to java.lang or very core types, but not for
> > things that just seem very very generic.
> >
> > Just my -1,
> >
> > Hen
> >
> > On Sat, 22 Jun 2002, Stephen Colebourne wrote:
> >
> > > I would like to add the following to Lang
> > >
> > > public interface Factory {
> > >   public Object create();
> > > }
> > >
> > > plus associated FactoryUtils class
> > >
> > >
> > > public interface Identifiable {
> > >  public String getIdentifier() {
> > > }
> > >
> > > plus associated IdentifiableUtils class (depends on Factory, as creating
> an
> > > identifier should be pluggable)
> > >
> > > Any opinions?
> > >
> > > Stephen
> > >
> > >
> > > --
> > > To unsubscribe, e-mail:
> <mailto:commons-dev-unsubscribe@jakarta.apache.org>
> > > For additional commands, e-mail:
> <mailto:commons-dev-help@jakarta.apache.org>
> > >
> > >
> >
> >
> > --
> > To unsubscribe, e-mail:
> <mailto:commons-dev-unsubscribe@jakarta.apache.org>
> > For additional commands, e-mail:
> <mailto:commons-dev-help@jakarta.apache.org>
> >
>
>
> --
> To unsubscribe, e-mail:   <mailto:commons-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>
>
>


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


Mime
View raw message