commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Keith Bennett" <keithrbenn...@gmail.com>
Subject Re: Instantiating Utility Classes
Date Thu, 31 May 2007 04:03:45 GMT
Stephen -

Thanks for responding.  Is it safe for me to assume that these public
constructors will never become deprecated or nonpublic?  This is very
important to me.

Also, would it be possible for someone to amend the Javadoc to say
what you just said, so that other people will know it's ok to use it
for this purpose?

Thanks very much for your work.  I've benefited much from it on
several projects.

- Keith Bennett


On 5/30/07, Stephen Colebourne <scolebourne@btopenworld.com> wrote:
> Keith Bennett wrote:
> > Recently I started using Velocity and JEXL for expression evaluation
> > so that users can write templates that format the data the way they
> > like.  I figured it would be really handy to give them access to
> > StringUtils, WordUtils, DurationFormatUtils, etc.  But these
> > templating tools require that you pass an instance into the context
> > and call static methods via that instance reference; one cannot call
> > ClassName.staticMethodName().
> >
> > Unfortunately, instantiating these utility classes is not recommended.
> > The StringUtils constructor Javadoc at
> > http://jakarta.apache.org/commons/lang/api-release/org/apache/commons/lang/StringUtils.html
> >
> > says "StringUtils instances should NOT be constructed in standard
> > programming."
>
> The only reason that the constructor is public at all is so it can be
> used in Velocity. So, go ahead and use it :-)
> Stephen
>
>
> >
> > Of course I could write my own object that delegates to every single
> > method in the respective class, but that seems kind of silly.  Is
> > there any reason why it would be a bad idea to support creating
> > instances of the utility classes?  I realize that naive programmers
> > use instances when it is better to use classes, but I think I have a
> > legitimate need here.  Also, if the class were made final, then the
> > confusion of static methods not following the same rules as nonstatic
> > methods with inheritance could be avoided.
> >
> > How can I find out if there has already been discussion of this, or if
> > not, how can I submit a request?  Do you have any suggestions how to
> > deal with this issue?
> >
> > Thanks.
> >
> > - Keith Bennett
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: commons-user-help@jakarta.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-user-help@jakarta.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org


Mime
View raw message