tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <craig...@apache.org>
Subject Re: Tag object pooling and immutability in the servlet spec
Date Fri, 25 Oct 2002 17:11:06 GMT


On 24 Oct 2002, Mr. Tomcat wrote:

> Date: 24 Oct 2002 17:37:36 -1000
> From: Mr. Tomcat <tomcat@mobile.mp>
> Reply-To: Tomcat Users List <tomcat-user@jakarta.apache.org>
> To: tomcat-user@jakarta.apache.org
> Subject: Tag object pooling and immutability in the servlet spec
>
> Is there a way to turn off tag object pooling?  Object pooling was a
> cool performance technique in earlier versions of Java, but now object
> creation is very fast, so it no longer serves a performance function,
> and it introduces extra complexity into tag object design.  Is this
> misfeature going to be phased out?
>

No.  Your assumption that it "no longer serves a performance function" is
not correct.

Just as an example of why it still matters, consider something like this
(using the JSTL iteration tag):

    <c:forEach var="i" begin="0" end="999">
      <mytags:foo index="${i}" .../>
    </c:forEach>

The tag reuse mechanisms allow a page compiler to create one instance of
the <mytags:foo. tag and reuse it for every iteration through the loop,
instead of creating 1000 of them.  No matter how cheap object creation
gets, there is still a difference -- and that difference is still
significant on webapps with large numbers of users.

If tag reuse really makes your tags more complex, you're probably
designing them wrong (and I'm talking to myself as well; I've been guilty
of that particular mistake).

> Also, on the immutable object topic, it seems that it would be better to
> have all the initialization of servlets and filters done in the
> constructor, not by calling an init function.  If everything could be
> set in the constructor, then all instance fields could be private final,
> meaning that the servlet or filter object could be immutable, and
> therefore known to be threadsafe, which is an issue with servlets.  Any
> chance of these changes happening in future releases of the servlet
> spec?
>

The constructor of a Servlet (or Filter) doesn't have access to the
ServletConfig (or FilterConfig) object, so it cannot acquire
initialization parameters, a reference to the ServletContext instance, or
anything like that.

Because javax.servlet.Servlet and javax.servlet.Filter are interfaces (not
classes), you can't declare constructors in them.  Therefore, the servlet
spec requires that there be a zero-args constructor available so that
instances can be dynamically instantiated.

Would it be possible to require servlets and filters to have a constructor
that takes a ServletConfig (or FilterConfig) argument?  Sure ... at the
cost of breaking every Servlet or Filter that has ever been written.
Doesn't seem like a smart idea to implement something that is purely
cosmetic, and wouldn't change the actual functionality provided by the
container.  There's much more important things for the spec to address.

> Thanks

Craig McClanahan




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


Mime
View raw message