commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Rall <>
Subject Re: Comment on (re-vote) XxxUtils constructors
Date Wed, 21 Aug 2002 07:50:25 GMT
Steve Downey <> writes:

> On Sunday 18 August 2002 09:55 am, Geir Magnusson Jr. wrote:
> > On 8/18/02 9:47 AM, "Stephen Colebourne" <>
> >
> <SNIP/>
> > I'm sorry if this is something everyone has gone over before.
> >
> > This isn't what velocity might use.  It's what *users* of Velocity might
> > use.  The Velocity core doesn't need such things - but users tend to use
> > Velocity in frameworks where they setup lists of classes of which instances
> > are made available for use in the template.
> >
> > We pushed stuff out of Velocity and Turbine into commons[-sandbox] for
> > people to share and use.  If they now are going to evolve so people using
> > Velocity and Turbine and Maverick and WebWork and... Can't share and use
> > them, we'll just have to either make wrappers (stupid) or fork (even
> > stupider) and keep available in Velocity or Turbine projects.
> If one of the goals of commons is to take reuseable code out of projects like 
> Velocity, Avalon and Tomcat, and make them generically useful, it seems to me 
> to be terribly counterproductive to take their code and make it useless for 
> the donor project. Not just change the API a little, but make it completely 
> unuseable.

Indeed, nothing but agreement here Steve.

> Now, I can see the arguments that it should be possible for Velocity to 
> execute static methods on an object without an instance of the object. But it 
> can't. It isn't likely to soon. So a known client of the StringUtils class is 
> not going to be able to use it. Period. Forking it isn't a question. Commons 
> has already forked it. 

Not to split hairs, but Velocity in fact can be configured to do just
that.  However, to accomplish this you have to plug in an alternate
introspection engine!  Requiring donor projects to jump through hoops
to re-use the code which they donated doesn't make sense, and as Steve
alludes to, is clearly not in the spirit the Commons charter.

> Jason van Zyl recently complained about code reformatting. I think that's 
> wrong. Commons owns the code, regardless of where it came from. Local 
> conventions should apply. If Turbine adopts the commons fileupload, they 
> won't ever see the source. However, if it were changed in some way that made 
> it really unuseable for Turbine, he'd have a legit gripe.

If only that were true.  Looking at the active developers for many of
the Commons projects, you'll notice that (in the usual case) that they
consist primarily of developers from the donor project.

> There's no technical reason why instances of StringUtils can't be constructed. 
> They're a bit useless in the Jave language, but quite useful in the Velocity 
> language. They might be useful in other languages that run in the Java VM. 
> Objections to the constructor amount to either, "I don't like that.", or 
> "People who do that are dumb."  Neither are good messages for a commons.

Indeed.  Public constructors are necessary for Class.newInstance(),
and hence for common class loading implementations (the use case
pointed out for Velocity users).

It makes zero sense to reduce the usability of Commons code to placate
language lawyers.

Daniel Rall <>

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

View raw message