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 Sat, 14 Sep 2002 10:46:45 GMT
All your points are well made. It was late and I wasn't thinking straight
;-)

I think I agree that using [lang] is better than using [util], which isn't
really going places.

IMHO:
[lang] = java.lang helpers + java.util helpers - java.util Collection
helpers

Stephen

From: "Steve Downey" <steve.downey@netfolio.com>
On Friday 13 September 2002 06:50 pm, Stephen Colebourne wrote:
> 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].
>

Logging is avoidable. And java.lang itself has dependencies on
java.security.
As well as java.util, java.io, and a bunch of others. Use of the rest of the
standard API shouldn't exclude a class. Otherwise CompareToBuilder will need
to go elsewhere, since Comparator is in java.util. [reductio ad absurdum
arguments never work with me, either]

The java.security dependency is internal. It's actually a dependency on
SecureRandom, which has been in place since JDK 1.1.8 (at least).

It really does belong in a 'util' package, for the same reasons that Date,
Calendar, Properties, Random, ... are in java.util. They're foundational,
but
not language support. I'm arguing that we're already putting those classes
into commons.lang. Except for collections. Which Sun should have separated
out, anyway.

> 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.

You can't include the typesafe class. If you do, it's not typesafe. <g>
The idea is that concrete types that need a unique identifier declare their
own ID class whose supertype is Object. Otherwise you end up with APIs that
take generic IDs that should take only a specific types.

>
> Stephen
>
> BTW: You left a netfolio constant in your attachment ;-)
>
Yeah, I know. But getting rid of it would have required more surgery than I
was willing to do at the moment. The right thing to do is to add a namespace
parameter to fromReadableString().


--
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