questions regarding adoption of JSTL

[Br...@alltel.com]

I have several questions regarding the adoption of JSTL.  If these sort
of questions are better suited for the "users" mailing list, I
apologize.  

My company is using several custom tag libraries and I'm trying to
determine our strategy for moving to the JSTL tag libraries.  This email
has to do more with "when" than "if" to adopt JSTL.  Meeting the
requirement of a Servlet 2.3/JSP 1.2 compliant container is not an issue
for us as we are already targeting app/web servers that support these
versions of the specifications.

We are about to begin creating many JSPs for many applications so we are
trying to be forward looking in our design decisions and want to
incorporate JSTL into our design as soon as possible.  However, we have
several concerns.

Performance is a major issue for us so the optimizations that servlet
containers will be able to provide once the standard is finalized is
very appealing to us.  I have a couple of questions regarding this
issue:

1.  How will the servlet container vendors be able to recognize what is
a JSTL tag in order to optimize the code that their page compiler
generates?  For example, what if I want to extend one or more of the
JSTL tags or supporting classes?  How much can I extend/change without
breaking this "optimization" benefit?

2.  What I've read in JSTL 1.0 Public Draft document leads me to believe
that there are performance losses when using the expression language
compared to java scriptlet within the JSP.  How substantial is this loss
of performance?  What I would be more interested in is the general
performance of the expression language compared to current methodologies
of tag-based tasks.  I realize this is a open-ended question -- but
generally speaking, is tag-based processing that uses EL slower than the
same task in a tag without EL?  I'm concerned that any performance
gained by the ability for servlet containers to generate optimized
servlets will be offset by the introduction of the expression language.


What also plays into our decision of when to move to JSTL is the ability
to use the EL in ALL of our tags -- not just JSTL tags.  I have a couple
of questions regarding this:

1.  In the "Expression Language Overview" section of the of the JSTL
public draft, it states that by the time JSTL publishes its final draft,
a stable definition of the expression language will exist.  The way I
interpret this is that once the JSTL publishes its final draft (next
month), I can implement the expression language that JSTL uses in our
custom (non JSTL) tags and can be assured that when JSP 1.3 is released
my tags will still work.  Is this a correct assumption?  I'm curious to
know what others are doing regarding this issue with custom tags?  Are
they just going to mix the JSTL tags which use EL with custom tags that
don't use EL?  This leads me to my next question.  If I wait until JSP
1.3 is released to start using EL in my custom tags, I could save myself
the work of incorporating EL into my tags now because it will work
automatically with JSP 1.3 -- right?

Thanks in advance.

Brennan





--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: questions regarding adoption of JSTL

[Shawn Bayern <ba...@essentially.net>]

Brennan,

Good questions.

> 1.  How will the servlet container vendors be able to recognize what
> is a JSTL tag in order to optimize the code that their page compiler
> generates?  For example, what if I want to extend one or more of the
> JSTL tags or supporting classes?  How much can I extend/change without
> breaking this "optimization" benefit?

The servlet container will be able to recognize JSTL tags by their
namespace and local names.  Every tag library has a namespace URI, and
it's this identifier that uniquely represents the tag library.

The optimizations that containers can make is not based on the actual
implementation classes.  Of course, containers can optimize the
tag-handler implementation classes as much as they'd like, and they can
expose these optimized versions for you.  But extending a tag-handler
implementation class isn't an operation specifically supported by the JSTL
standard.  In fact, the very means for potential container-based
optimizations comes from the fact that JSTL doesn't require a particular
kind of implementation for its tags.  A container need not even use a tag
handler; it's expected that a noticeable performance increase can come
from a container that "in-lines" code implementing a JSTL tag directly in
the source code to the servlet it generates.

> 2.  What I've read in JSTL 1.0 Public Draft document leads me to
> believe that there are performance losses when using the expression
> language compared to java scriptlet within the JSP.  How substantial
> is this loss of performance?

I don't have statistics, but the JSTL reference implementation does cache
parsed expressions, which makes the implementation very efficient --
keeping in mind that expressions are still interpreted, not compiled.  I
have thought a lot about how a container might be able to compile
expressions in the JSTL expression language in JSP 1.3 -- when this
language is expected to be a standard feature of the container -- but I'm
not yet convinced that this sort of "compilation" can be meaningfully
better than interpretation.

To be honest, it sounds like empirical profiling would be more useful to
your environment than my theoretical guesses.  :-)  The JSTL reference
implementation is essentially in its final form right now; there will be
minor changes, but I don't expect anything about the overall structure or
implementation strategy to change, meaning that it should run
approximately as quickly now as once it's released.

> 1.  In the "Expression Language Overview" section of the of the JSTL
> public draft, it states that by the time JSTL publishes its final
> draft, a stable definition of the expression language will exist.  
> The way I interpret this is that once the JSTL publishes its final
> draft (next month), I can implement the expression language that JSTL
> uses in our custom (non JSTL) tags and can be assured that when JSP
> 1.3 is released my tags will still work.  Is this a correct
> assumption?

No, not exactly.  You can be assured that the JSTL 1.0 expression language
will continue to be supported for implementations that wish to use JSTL
1.0.  JSP 1.3 reserves the opportunity to modify the expression language.  
My expectation is that it won't do this lightly, but it may decide to add
features or to modify slightly the semantics of existing features.  But if
you implement the language, you will indeed have implemented something
standard and supportable.  Or, of course, you're welcome to use the
reference implementation's version.

> I'm curious to know what others are doing regarding this issue with
> custom tags?  Are they just going to mix the JSTL tags which use EL
> with custom tags that don't use EL?  This leads me to my next
> question.  If I wait until JSP 1.3 is released to start using EL in my
> custom tags, I could save myself the work of incorporating EL into my
> tags now because it will work automatically with JSP 1.3 -- right?

Yes, although if you use the RI's interpreter, the integration is as
simple as calling a static method with (I think) four or five arguments:  
e.g., the expression to parse, the type you expect back from the
expression, the PageContext (for data retrieval), and so on.  The
difference in JSP 1.3 is that the issue becomes the container's burden,
not the tag developer's.

Hope that helps,

-- 
Shawn Bayern
Author, "JSP Standard Tag Library"  http://www.jstlbook.com
(coming this summer from Manning Publications)


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>