commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Henri Yandell <>
Subject Re: [lang][collections] Utils having a public constructor
Date Tue, 13 Aug 2002 20:02:08 GMT

> > > Yes, that would work.  However, it would break compatibility for
> > > anyone already using StringUtils.
> >
> > But StringUtils hasn't been released yet.  It's in beta, yes?
> > And the beta version had a private constructor. ?
> Portions of the code frrom StringUtils came from the Turbine project
> (and possibly JServ before that), and has been in production use for
> years.

To be fair, StringUtils has changed a lot and anyone dependent on the old
turbine code would most likely have made themselves known a while back.
Methods were renamed, or thrown away due to not being generic enough.

The private() was a pretty new addition a month or so prior to going beta,
so I don't think anyone will be hurt by the private() being loosened. As
to anyone who was being hurt by the introduction of the private(), I think
Velocity style users would be the only one and Maven is the only one to
have stood up so far.

Lastly, this is not a StringUtils issue but a Commons.XXxxUtils issue. The
current public() is there as a favour to Jason, but I'm anxious that a
general Commons decision is made that we can all adhere to.

Do we do public() as it's easy for Velocity/other-tools, and we assume our
consumers can figure out that instantiating a class with only static
methods is a bit thick.

Do we do private() and tell Velocity to get its act together and stop
using a loophole. The fact that Collections/Array have private() makes
this a fine stance to take I'd have thought, unless Velocity only cares
about String-based utilities.

Do we do protected() and have some kind of back-door system in which
people who need to use a Utils as an instance can extend it and use it
that way [or do we provide an extended instance somehow?] and most
consumers never know that the extension is not possible.

Getting a decision on that is needed, StringUtils itself will just follow
suit. The backwards compatibility only affects people if they have
released a XxxUtils with a public constructor??


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

View raw message