I doubt that they will be made non-public, as this reason still applies. If you would like, please raise a JIRA call to get the javadoc clarified further.
Stephen ----- Original Message ---- From: Keith Bennett <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
