commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael A. Smith" <>
Subject RE: [VOTE] (re-vote) XxxUtils constructors
Date Mon, 19 Aug 2002 18:50:49 GMT
On Mon, 19 Aug 2002, Jack, Paul wrote:
[lots of good stuff snipped...  well said Paul]

> The "privateers", in fact, have been actively suggesting compromises,
> things that seemed like they would work within the existing Velocity
> scheme but not require a public constructor.  Those solutions turned
> out to be inadequate, as we discovered only after the opposition stopped
> ignoring them completely.

I've got one more suggestion as well that I *know* will work with 
private constructors.  See below.

> The privateers have also been willing to mutate into things like 
> protected or deprecated public constructors, which would at least 
> prevent direct instantiation or issue severe warnings about the 
> practice of using the constructors.  To date these ideas have also
> been completely ignored.
> The privateers have been doing all the work to resolve a contentious
> issue, and have been rewarded with hostility, insults and now
> base sarcasm.

I'm not sure if things have gone *quite* that far.  Many of the 
non-"privateers" have been providing useful discussion in the debate. 

> Daniel Rall, the person who raised this issue, once accepted protected 
> constructors as a simple way for Velocity to provide its own publicly 
> available versions of utility classes.

I've thought a bunch about this whole debate, and I am now an adament -1 
for non-private constructors (deprecated or not).  

Regarding a public constructor (deprecated or not):  I believe Paul 
voiced most of the issues that I would raise here.  I'd like to 
emphasise these two though:
 - poor design (static utility methods in a class does not make it a 
bean and thus the class should not be treated as such)
 - maintenance headaches (backwards compatibility based on things being 
more accessible)

Regarding a protected constructor (deprecated or not):  Having the
constructor protected does nothing for solving the issue of making a
static utility class into a bean for use in bean-based tools.  All it
does is leave room for the capability of writing such a "bridge" class
where a subclass of the utility class widens the access to the
constructor to public (thus making it "accessible" as a bean).  If a new
class is going to be written anyway, then I think it would be much
better to be written like this:

   *  A bean-like representation of the static utility methods found in
   *  StringUtils
  public class StringUtilsObj {
    public StringUtilsHelper() { }

    // btw, shouldn't this be capitalize rather than capitalise?
    public String capitalise(String str) {
      return StringUtils.capitalise(str);
    // ...
    public String strip(String str) {
      return StringUtils.strip(str);
    // ...
    public String upperCase(String str) { 
      return StringUtils.upperCase(str);

Thus, whomever wants the static utility class to act/behave as a bean
can construct such a bean that has methods that pass through to the
static utility class.  No need to have a protected constructor.  And 
actually, this class would work just fine instead of a public 
constructor as well.  

In essence, I think this is the solution that can make people happy. We
can have a private constructor to keep a non-bean static utility method
based class uninstantiatable, but there is the ability to create a
bean-based version of such a utility class for the tools that require a
bean-like class.

Even though there is added maintenance, I have no objections to having
such a bean-based wrapper in commons components themselves rather than
in projects that are utilizing the static methods (e.g. velocity users).  
Thus, within lang, collections, etc., wherever there is a XxxUtils
class, a cooresponding XxxUtilsObj (or XxxUtilsBean or whever people
think is best) class also exists.  Whenver a new static utility method
is added to a Utils, a new member function is also added to the



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

View raw message