Re: Tag object reuse (pooling) in jsp 2.0?
On Thu, 2003-01-23 at 04:02, Felipe Schnack wrote: 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 are created and destroyed... seems to me that we are freeing a lot of work from gc... gc is a resource intensive process. Do you have any evidence of that? gc was resource-intensive on the original JVMs, but on modern ones, it is very fast. Either you manage your own memory, or you have a gc do it. If we wanted to manage our own memory we would still be using C++. It turns out that computers are much better at handling memory management than human programmers are. I would be very happy to trade a little bit of performance for a lot of security, especially on applications like web servers. Hm... I don't know, but the way tags receive their fields now (getters and 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? Your idea is to have field name as the keys in the map? Yes, that's exactly my idea. Setter methods are generally not a good idea. Immutable objects have many many advantages: They are completely thread-safe, and they tend to be easier to debug and work with, because if you can ensure that they are constructed in a correct state, they will always remain in a correct state. This is a little counter-intuitive, but there are performance benefits to immutable objects, too. That's why I think that tags should have a constructor which takes a Map, and that way, it doesn't need any setter methods. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Tag object reuse (pooling) in jsp 2.0?
On Wed, 2003-01-22 at 17:08, Craig R. McClanahan wrote: JSP 2.0 also introduces a new tag API called SimpleTag. Besides being much easier to program, you don't need to worry about pooling and reuse of them; they are created as needed by the container. I'm glad to hear that. That is a more contemporary way to do this. There aren't any milestone builds of Tomcat 5 (which implements Servlet 2.4 and JSP 2.0) yet, but it's not all that hard to build from source if you want to play with this. I'll give it a try. It's going to be a good one. Thanks -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Tag object reuse (pooling) in jsp 2.0?
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 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 and 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? Your idea is to have field name as the keys in the map? -- Felipe Schnack Analista de Sistemas [EMAIL PROTECTED] Cel.: (51)91287530 Linux Counter #281893 Centro Universitário Ritter dos Reis http://www.ritterdosreis.br [EMAIL PROTECTED] Fone/Fax.: (51)32303341 -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Tag object reuse (pooling) in jsp 2.0?
I am guessing you are referring to custom tags? Do you have a link to more information about this because I am new to custom tags and have never heard of this before. Of course I would want to write my tags the right way, whichever way that is... Erik Joe Tomcat wrote: 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'm hoping that it will, for two reasons. First, that will make writing tags simpler. The whole reason we are using Java instead of C++ is because in Java we let the GC do the cleanup work for us. That results in much more stable software. 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. Opinions? -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Tag object reuse (pooling) in jsp 2.0?
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'm hoping that it will, for two reasons. First, that will make writing tags simpler. The whole reason we are using Java instead of C++ is because in Java we let the GC do the cleanup work for us. That results in much more stable software. 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. Opinions? -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Tag object reuse (pooling) in jsp 2.0?
On 21 Jan 2003, Joe Tomcat wrote: Date: 21 Jan 2003 05:46:53 -0800 From: Joe Tomcat [EMAIL PROTECTED] Reply-To: Tomcat Users List [EMAIL PROTECTED] To: Tomcat Users List [EMAIL PROTECTED] Subject: Tag object reuse (pooling) in jsp 2.0? 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? Best way to find out is to go get the spec :-). http://java.sun.com/products/jsp/download.html For backwards compatibility, the programming requirements on old-style tags (javax.servlet.jsp.tagext.Tag and friends) remains the same -- you have to program your tags to operate correctly in a pooled environment. JSP 2.0 also introduces a new tag API called SimpleTag. Besides being much easier to program, you don't need to worry about pooling and reuse of them; they are created as needed by the container. There aren't any milestone builds of Tomcat 5 (which implements Servlet 2.4 and JSP 2.0) yet, but it's not all that hard to build from source if you want to play with this. I'm hoping that it will, for two reasons. First, that will make writing tags simpler. The whole reason we are using Java instead of C++ is because in Java we let the GC do the cleanup work for us. That results in much more stable software. 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. Opinions? Craig -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
