commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jack, Paul" <>
Subject RE: [lang][collections] Utils having a public constructor
Date Mon, 12 Aug 2002 19:33:48 GMT
Actually, I've been thinking for a while now that I'd like to see
the utility constructors in [collections] be, at least, protected.
That way people could extend our libraries to add their own static
utility methods and inherit all of ours.  For instance, we can't
use the JDK's naming convention (making an interface name plural)
because they made java.util.Collections's constructor private.  If
they had made it protected, we'd have been able to extend it to add
our own utility methods; people could get all of our new utility
methods just by changing the import...

So, I'm not against visible constructors.  However, in my ideal 
universe, the constructors are (1) protected to make it clear what
they're for and (2) exceptional; any attempt to actually instantiate
a CollectionUtils would raise a runtime (um, UnsupportedOperation?)

Would the Velocity folks mind including something like this in 

    public class Util extends Object {

        final public StringUtils string = null;
        final public ObjectUtils object = null;
        final public CollectionUtils collection = null;

        public Util() {


Then they'd use the Util class instead of the individual libraries;
and could invoke the methods by saying Util.string.method() instead
of StringUtils.method().


> -----Original Message-----
> From: Henri Yandell []
> Sent: Monday, August 12, 2002 12:00 PM
> To: Jakarta Commons Developers List
> Subject: [lang][collections] Utils having a public constructor
> On Mon, 12 Aug 2002, Stephen Colebourne wrote:
> > I actually quite strongly dislike making the constructor public. Its
> > basically a flaw in Velocity that we're coding for.
> >
> > However, in the spirit of cooperation, I am willing to see a public
> > constructor. However, I want it to be deprecated. The 
> deprecation won't
> > affect tools like Velocity that instantiate it by 
> Class.newInstance(), but
> > will cause ordinary programmers to realise that they are 
> using the class
> > wrongly.
> Jason/Geir, is this acceptable?
> >
> > Also, if we do this to one static utility class, we do it 
> to all. That means
> > changing the [lang] developers guide and making the 
> changes. It also affects
> > [collections] and [pattern]
> Agreed. We either go one way or the other. With the 'spirit of
> cooperation' I aimed to do the minimal number of changes necessary.
> Collections peoples... what is your viewpoint?
> Hen
> --
> To unsubscribe, e-mail:   
For additional commands, e-mail:

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

View raw message