commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stephen Colebourne" <scolebou...@btopenworld.com>
Subject Re: [lang][util] GUIDs: was Open Symphony OSCore
Date Fri, 13 Sep 2002 22:50:39 GMT
From: "Steve Downey" <steve.downey@netfolio.com>
> I don't think they should go into Pattern, although pattern would use
them.
> They're a little more fundemental than pattern. In my system, they're in
> util, but the sandbox util is being spread across many packages.
>
> I've put them into lang in what I've attached. They aren't to dissimilar
in
> spirit to RandomStringUtils. Although they do have dependencies outside of
> java.lang. In particular java.security. And logging, at the moment, is JDK
> 1.4. Logging could be dropped. It's only where exceptions are thrown, and
the
> information could be carried in the exception.

My point is that the identifier generators in pattern shouldn't be in
[pattern]. But equally, given the dependencies on security and logging, your
UUID code can't be in [lang].

This leaves [util] or a new [identifier] package. This is the recurring
problem with [util], in that a collection of useful utilities doesn't make a
releaseable project.

If it was a separate [identifier] project, it could include the typesafe
class given below, plus the other implementations of identifiers from
[pattern]. It would depend on [lang] and [pattern]. Longer term it would be
included in the core.jar combined build.

Stephen

BTW: You left a netfolio constant in your attachment ;-)

> I will also say that I've found, in practice, using UUIDs in raw form can
be
> very dangerous. You lose type safety. A UUID in an API conveys all the
safety
> of Object, or (void*) in C. In use I wrap (not inherit) them like so:

public class StrategyID implements Serializable {
    private UUID id;

    public StrategyID() {
        setID(new UUID());
    }

    public StrategyID(UUID id) {
        setID(id);
    }

    public StrategyID(String id) {
        setID(new UUID(id));
    }

    public void setID(UUID id) {
        this.id = id;
    }

    public UUID getID() {
        return id;
    }

    public String toString() {
        return id.toString();
    }

    public int hashCode() {
        return id.hashCode();
    }

    public boolean equals(Object o) {
        if (o == this)
            return true;
        if (!(o instanceof StrategyID))
            return false;
        StrategyID rhs = (StrategyID) o;
        return this.getID().equals(rhs.getID());
    }
}



On Friday 13 September 2002 04:18 pm, Stephen Colebourne wrote:
> Two points:
> 1) We have been a little slow in getting all the code offered from Avalon
> included in commons. We have to be careful not to take too much on.
>
> 2) I'm not certain as to which of the OSCore methods fit with commons yet.
>
> Having said that, here's a first look:
> BeanUtils to [beanutils]
> Data/DataUtil is a little odd. If the use is explained, maybe [util]
> DateUtil could go with [lang]s upcoming date code.
> FileUtils to [io]
> GUID would fit with the identifier factories in [pattern]. (Although they
> shouldn't be in pattern)
> TextUtils contains a lot of HTML specific methods which don't apply to
> [lang].
> XMLUtils might fit with [util] but it adds to the dependencies.
>
> Stephen
>
> ----- Original Message -----
> From: "Daniel Rall" <dlr@finemaltcoding.com>
> To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
> Sent: Friday, September 13, 2002 6:52 PM
> Subject: Re: [lang][collection][util] Open Symphony OSCore
>
> > Henri Yandell <bayard@generationjava.com> writes:
> > > I talked to Mike Cannon Brookes of Jira and Open Symphony fame. He
> > > mentioned that we might want to look in the OSCore package there:
> > >
> > > http://www.opensymphony.com/oscore
> > >
> > > and consider aggregating in any applicable works in there. I took a
>
> quick
>
> > > look at TextUtils and expect to roll a few methods in at some stage.
> > > Thought I'd let you all know that it's open season on OSCore :)
> > >
> > > I was going to reimplement the TextUtils ones as they were quite
light,
>
> at
>
> > > least the first ones I was considering, but I think we could probably
> > > discuss a formal submission of something if there was something
complex
> > > that looked like a good fit.
> > >
> > > Another thing we could do is provide an API map showing which Jakarta
> > > Commons classes could easily replace theirs. They might be interested.
> > >
> > > Licence wise, it's a modified Apache, so hopefully compatible.
> >
> > Henri, sounds good.  Does this mean we should branch?  It seems like
> > quite a bit of functionality is getting added in between beta and
> > release candidate (though you guys are doing a great job with the unit
> > tests!).
> > --
> >
> > Daniel Rall <dlr@finemaltcoding.com>
> >
> > --
> > 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