commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject [Lang] Increasing its role [was: Re: [Reflect] Summary of points and relationship with BeanUtils]
Date Wed, 19 Jun 2002 07:47:01 GMT
>  from:    Henri Yandell <>
> On Wed, 19 Jun 2002, Stephen Colebourne wrote:
> > c) decide on whether the naming convention in [Lang] is xxxs as with Strings
> > at present, or xxxUtils as with StringUtils (ie. what [Collections] adopted.
> It used to be all xxxUtils and the decision was made to go away from it
> when they broke out of the Util sub-project.

OK. Like collections will have, there should be a note somewhere in the project (developers
guide?) to say that is the naming convention.

> > d) consider other additions to [Lang]
> >    - a Serialization class, with a method that clones via serialization
> Heh. Someone wrote an article on this a year or so back and it's
> languished in my xxx.lang package ever since. Am happy to begin by
> committing that unless someone has a version they've nurtured into
> something more useful.

My version is at

Note that the serialize and deserialize methods on Objects should probably be moved to Serialization
if the class is to be created. Else put the serialization clone method on Objects.

The Identifiable interface and Identifier class should also be considered (from the above
link), this came up in a Bewtixt thread. (although Identifier would need to be made pluggable)

> >    - a StringBuffer class, with the same methods as Strings, but for a
> > StringBuffer.
> Sounds good. Seems to me there is a better way though. java.lang.String
> and StringBuffer don't share that many functionalities from memory. In
> Strings the code either manipulates it as a String, or turns it to a
> StringBuffer. I would hope that despite having two classes, there would
> really only be one implementation method and one method that redirects.
> However these methods would not all live in Strings, or all live in
> StringBuffers.
> I imagine that the StringBuffer methods would pass in a StringBuffer
> expecting that to be modified and not to have a StringBuffer returned?? Or
> if one is returned [as often is the case in java.lang.StringBuffer] that
> it would return the one passed in.

No, what I meant was an instantiable StringBuffer, not a StringBufferUtils. Thus you write
UStringBuffer buf = new UStringBuffer();
thus the buffer can be manipulated accordingly. (UStringBuffer would implement all the methods
of StringBuffer for compatability). BTW, there is probably a better name!

Also, there was a discussion on JavaLobby recently where direct manipulation of char arrays
was requested. So maybe there should be a Chars utility class with all the functionality,
which Strings and UStringBuffer delegate to.

> > e) release [Lang] as a full commons project
> Won't argue. Lang seems to be cropping up as a project that a few others
> are dependant on, so having a release would be nice.
> It would be nice to have more unit tests, mavenise it, doc more, hack out
> ugly String overloads. The biggest issue I'm finding as I use the methods
> is that a lot aren't null safe.
> Once Lang is released, then I can release a 1.0 of String taglib depending
> on it. So time for me to focus hard on Lang I think.

All makes sense. Hopefully when my CVS is confirmed I can contribute?


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

View raw message