commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Rall <...@finemaltcoding.com>
Subject Re: [lang][collections] Utils having a public constructor
Date Mon, 12 Aug 2002 22:06:46 GMT
"Jack, Paul" <pjack@sfaf.org> writes:

> > > Actually, I've been thinking for a while now that I'd like to see
> > > the utility constructors in [collections] be, at least, protected.
> > 
> > +1 Paul, my thoughts exactly.
> 
> Well, not exactly. :)

Apparently not.  :)

> In my ideal universe, the protected constructors throw RuntimeExceptions.
> So you wouldn't actually be able to create an instance.

You can't create an instance with a protected ctor anyhow (unless
you're trying to do it from within the same package, or a sub-class).

> Actually, even with a protected constructor, Class.newInstance() will 
> still raise an IllegalAccessException and thus Velocity couldn't use it.

I suggested sub-classing and providing a public ctor.

> I really do think Velocity should be modified to allow static invocations
> without an instance.  There are other APIs not under our control that 
> use private constructors for their utility classes:
> 
>    java.util.Collections
>    java.util.Arrays
>    java.nio.channel.Channels
> 
> and so on.  So I really do believe that Velocity would benefit more from
> allowing statics without instances, rather than having us change all the
> commons utility classes.

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.

The invoker/wrapper class I suggested in other mails seems to statisfy
the most people, but I would personally much prefer a protected ctor
which doesn't conflict with Java's introspection facilities.

> But I'd still like to see protected constructors, it's a nice thing to
> do for users.

It's not so nice if the ctor implementations throw exceptions.  The
fact that they're protected makes it clear enough how they should be
used.
-- 

Daniel Rall <dlr@finemaltcoding.com>

--
To unsubscribe, e-mail:   <mailto:commons-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>


Mime
View raw message