Return-Path: Delivered-To: apmail-jakarta-commons-dev-archive@apache.org Received: (qmail 9769 invoked from network); 12 Aug 2002 22:06:43 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 12 Aug 2002 22:06:43 -0000 Received: (qmail 21649 invoked by uid 97); 12 Aug 2002 22:07:09 -0000 Delivered-To: qmlist-jakarta-archive-commons-dev@jakarta.apache.org Received: (qmail 21446 invoked by uid 97); 12 Aug 2002 22:07:08 -0000 Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Jakarta Commons Developers List" Reply-To: "Jakarta Commons Developers List" Delivered-To: mailing list commons-dev@jakarta.apache.org Received: (qmail 21389 invoked by uid 98); 12 Aug 2002 22:07:08 -0000 X-Antivirus: nagoya (v4198 created Apr 24 2002) Sender: dlr@finemaltcoding.com To: "Jakarta Commons Developers List" Subject: Re: [lang][collections] Utils having a public constructor References: From: Daniel Rall Date: 12 Aug 2002 15:06:46 -0700 In-Reply-To: Message-ID: Lines: 53 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Common Lisp) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N "Jack, Paul" 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 -- To unsubscribe, e-mail: For additional commands, e-mail: