Return-Path: Delivered-To: apmail-jakarta-tomcat-user-archive@apache.org Received: (qmail 76868 invoked from network); 23 Jan 2003 12:03:08 -0000 Received: from exchange.sun.com (192.18.33.10) by 208.185.179.12.available.above.net with SMTP; 23 Jan 2003 12:03:08 -0000 Received: (qmail 15128 invoked by uid 97); 23 Jan 2003 12:04:07 -0000 Delivered-To: qmlist-jakarta-archive-tomcat-user@jakarta.apache.org Received: (qmail 15113 invoked by uid 97); 23 Jan 2003 12:04:07 -0000 Mailing-List: contact tomcat-user-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Tomcat Users List" Reply-To: "Tomcat Users List" Delivered-To: mailing list tomcat-user@jakarta.apache.org Received: (qmail 15101 invoked by uid 98); 23 Jan 2003 12:04:06 -0000 X-Antivirus: nagoya (v4218 created Aug 14 2002) Subject: Re: Tag object reuse (pooling) in jsp 2.0? From: Felipe Schnack To: Tomcat Users List In-Reply-To: <1043156813.2037.11.camel@linux.local> References: <1043156813.2037.11.camel@linux.local> Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable X-Mailer: Ximian Evolution 1.0.3 (1.0.3-4) Date: 23 Jan 2003 10:02:38 -0200 Message-Id: <1043323358.2028.15.camel@desenv1.ritterdosreis.br> Mime-Version: 1.0 X-Spam-Rating: 208.185.179.12.available.above.net 1.6.2 0/1000/N X-Spam-Rating: 208.185.179.12.available.above.net 1.6.2 0/1000/N > The current wisdom on object pooling is "don't do it", with the > exception of expensive objects like database connections, etc. Right > now, jsp uses object pooling of tag objects, in theory to attain higher > performance. This might have made sense back in the old days, but now > must Tag objects are very simple with only a few fields, and can be > created and GCed very efficiently. Is tag object pooling going to go > away with jsp 2.0? I don't know, to me seems a good idea to pool tag instances. For people like me, that don't write a single line os scriptlet code, millions of tags= =20 are created and destroyed... seems to me that we are freeing a lot of work from gc... gc is a resource intensive process. > Right now, tags have to be written in > such a way that they do their own cleanup. The second reason is that > tags should have all their fields set in the constructor, perhaps using > a Map as an argument. This seems strange but has the advantage that the > tag object can then be made immutable, which has a large set of > benefits. Hm... I don't know, but the way tags receive their fields now (getters an= d setters) is good for me. Receiving lots of attributes in a Map don't look clean for me... much like get an array of objects, who will know what he/she will find in each index?=20 Your idea is to have field name as the keys in the map?=20 =20 --=20 Felipe Schnack Analista de Sistemas felipes@ritterdosreis.br Cel.: (51)91287530 Linux Counter #281893 Centro Universit=E1rio Ritter dos Reis http://www.ritterdosreis.br ritter@ritterdosreis.br Fone/Fax.: (51)32303341 -- To unsubscribe, e-mail: For additional commands, e-mail: