On 18/05/2021 15:42, Christopher Schultz wrote:
Mark,
On 5/17/21 14:47, Mark Thomas wrote:
Hi all,
I am looking at some of the optimizations requested in [1]
One of the examples is show below. Code like this is used when the JSP
calls a tag.
private boolean _jspx_meth_mytag_005fhelloWorld_005f0(
jakarta.servlet.jsp.PageContext _jspx_page_context)
throws java.lang.Throwable {
jakarta.servlet.jsp.PageContext pageContext = _jspx_page_context;
// mytag:helloWorld
....
}
The question is, can the generated code above be changed to something
like this:
private boolean _jspx_meth_mytag_005fhelloWorld_005f0(
final jakarta.servlet.jsp.PageContext pageContext)
throws java.lang.Throwable {
// mytag:helloWorld
....
}
To what end? Are you trying to remove a line of code? Are you trying to
remove another local variable? Improve performance?
Yes, yes and yes. :)
This was one small part of a group of changes that made a measurable
difference at scale:
https://bz.apache.org/bugzilla/show_bug.cgi?id=65124
How much this specific change contributed is TBD. I suspect only a small
amount.
I am assuming that the aliasing of _jspx_page_context to pageContext
is so that _jspx_page_context always references the original even if
the tag decides to do something like:
pageContext = new MyCustomPageContextImpl();
The question is, is behaviour like this allowed?
I can't see anything in the spec that disallows this.
I don't think the aliasing is a defence against malicious apps as it
is only the implicit objects that are protected this way. Internal
objects (those name _jsp*) are unprotected.
Given that the original authors (who were on the JSP EG at the time)
added this aliasing for the implicit objects, it looks like the
intention was to allow applications to manipulate/replace the implicit
objects if they wish - without breaking Jasper.
If the above assumptions are correct, what do we want to do about [1]?
The aliasing is often unnecessary but will sometimes be essential. Do
we reject this optimization request? Do we add a configuration option?
Do we try and make this aspect of the code generation pluggable
somehow? Something else?
If you could add an option like "make global-local-aliases final" and
then just add "final" to the declaration of that local variable when
it's "true" (and default==true), that would be a Good Thing. Release it
and see who, if anyone, complains. It's easy to disable, and we'll get
information on how much of a needed feature it is. I'd only make the
default==true in 10.x as to not disturb anyone unnecessarily.
Even that was starting to look a little invasive. At this point I think
I have done all I can for BZ 65124.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
