commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <>
Subject Re: [lang][collections] Utils having a public constructor
Date Tue, 13 Aug 2002 00:26:55 GMT

On 12 Aug 2002, Daniel Rall wrote:

> Date: 12 Aug 2002 16:28:11 -0700
> From: Daniel Rall <>
> Reply-To: Jakarta Commons Developers List <>
> To: Jakarta Commons Developers List <>
> Subject: Re: [lang][collections] Utils having a public constructor
> "Jack, Paul" <> writes:
> > > Introspection does not work without instances.  Given how JavaBeans
> > > work, and how long Velocity has had its existing behavior, change
> > > seems highly unlikely.  And since Geir has even done work towards
> > > making the behavior pluggable in CVS HEAD, not really necessary,
> > > either.
> >
> > I'm not sure I'm following.  Introspection is for JavaBeans.
> > StringUtils is not a JavaBean.  If Velocity is only meant to work with
> > beans, then it's not supposed to work with StringUtils, and there's
> > no issue.
> Velocity treats anything you put into its context in a bean-like
> fashion.  I agree that StringUtils is not a JavaBean.  Regardless,
> Velocity is able to use it in a bean-like fashion as long as there is
> an accessible ctor.  What value is there in preventing this behavior?
> Allowing this behavior allows re-use of Commons code, which directly
> matches the charter under which Commons components operate.

For StringUtils in particular, it's an issue of Velocity imposing it's own
particular design restrictions on a component that can be used just fine
in other environments.  One could equally argue that Velocity should
provide its own means for manufacturing wrapper classes around such
things, to meet the Velocity requirement for dynamic instantiation.

For singleton-implemented-as-static-class in general, there is no
guarantee that you won't mess up the functionality by being able to create
instances -- that's why people create private constructors in the first

For the "you must create instances through a factory" type designs, trying
to dynamically instantiating instances without the factory is most likely
to cause functional problems, because you're breaking the contract to
which the class was programmed.

> --
> Daniel Rall <>


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

View raw message