You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Stephen Colebourne <sc...@btopenworld.com> on 2002/09/13 22:18:47 UTC
Re: [lang][util] Open Symphony OSCore
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" <dl...@finemaltcoding.com>
To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
Sent: Friday, September 13, 2002 6:52 PM
Subject: Re: [lang][collection][util] Open Symphony OSCore
> Henri Yandell <ba...@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 <dl...@finemaltcoding.com>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [lang][util] GUIDs: was Open Symphony OSCore
Posted by Stephen Colebourne <sc...@btopenworld.com>.
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" <st...@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:
<ma...@jakarta.apache.org>
For additional commands, e-mail:
<ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [lang][util] GUIDs: was Open Symphony OSCore
Posted by Steve Downey <st...@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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [lang][util] GUIDs: was Open Symphony OSCore
Posted by Stephen Colebourne <sc...@btopenworld.com>.
From: "Steve Downey" <st...@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" <dl...@finemaltcoding.com>
> To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
> Sent: Friday, September 13, 2002 6:52 PM
> Subject: Re: [lang][collection][util] Open Symphony OSCore
>
> > Henri Yandell <ba...@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 <dl...@finemaltcoding.com>
> >
> > --
> > To unsubscribe, e-mail:
>
> <ma...@jakarta.apache.org>
>
> > For additional commands, e-mail:
>
> <ma...@jakarta.apache.org>
----------------------------------------------------------------------------
----
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [lang][util] GUIDs: was Open Symphony OSCore
Posted by Steve Downey <st...@netfolio.com>.
I took a quick look, and the GUID's aren't. It's a stringification in base 36
of a 160 bit random number. A nice random identifier, to be sure, but it's
not a GUID.
A GUID is a specific form of a DCE UUID. And DCE UUID's have a fairly specific
internal structure. The best reference is here
http://ftp.ics.uci.edu/pub/ietf/webdav/uuid-guid/draft-leach-uuids-guids-01.txt
Althought the draft is expired, parts were adopted into the DCE spec, and
parts into the WebDAV spec (RFC 2518)
The actual DCE spec is here:
http://www.opengroup.org/onlinepubs/9629399/apdxa.htm
(I know a couple people who do real DCE work. They refer to the Leach I-D. DCE
took what they needed. Then the IETF decided not to standardise UUIDs, since
there was an ISO standard that defined them. Typical standardese muddle.)
Now, I wouldn't be complaining if I didn't have a solution. I use UUIDs
extensively. And the class that implements them is pretty good. It does need
work in the javadocs.
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.
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" <dl...@finemaltcoding.com>
> To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
> Sent: Friday, September 13, 2002 6:52 PM
> Subject: Re: [lang][collection][util] Open Symphony OSCore
>
> > Henri Yandell <ba...@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 <dl...@finemaltcoding.com>
> >
> > --
> > To unsubscribe, e-mail:
>
> <ma...@jakarta.apache.org>
>
> > For additional commands, e-mail:
>
> <ma...@jakarta.apache.org>
Re: [lang][util] Open Symphony OSCore
Posted by Henri Yandell <ba...@generationjava.com>.
On Fri, 13 Sep 2002, 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.
It'll continue to go slowly, takes time for such a large chunk of code to
be picked over like the vultures we are :) Also, there's no reason to
accomodate code just because it could be added in this case.
>
> 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.
Anything that isn't a clean fit can happily be ignored.
Hen
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>