1 The Problem The current JSP compiler (Jasper) in tomcat 4.0 is essentially an one-pass compiler, with a two stage process. The Jsp page is first parsed, looking for JSP syntatic elements, and a list of generators for these elements are produced. At the second stage, these generators are visited to generate the java program, which is then compiled (by javac) into bytecodes.
Such a compiler is simple, light weight and fast, and works very well so far. However, it has the short-comings that are usually associated with an one-pass compiler. For instance, 1.1 It's hard to handle problems that require looking up info in another part of the page. For instance, enforcing the rule that taglib needs to be declared before use would be hard to implement. Right now, any custom tags used before declared are treaded as unprocessed tags (a bug). 1.2 It's hard to add new logic to the parts. For intance, currently, Xml view of the output is added on to the generators as a wrapper, instead of a set of generators on their own, on another visit. 1.3 It doesn't have an uniform error reporting mechanism. For instance, <%@ page import > directive are collected and generated outside of the generators, where the line number mapping from .java to .jsp files is non-functioning. 1.4 It's hard to do any optimization, other than the basic onces. For instance, optimizations such as taglib object reuse would be hard to do, since it's hard for the compiler to find out about the objects that were generated before. 2 The Proposed Compiler Structure I think it's time to do a rewrite of Jasper. The compilation would be a multi-pass process. 2.1 Jsp Syntax Tree The most important data structure is one that is the internal representation of the JSP page. Call it the Jsp syntax tree if you wish. It is produced by the parser, annotated by the validators, and modified and transformed by the optimizers. 2.2 The Parser It parses the origianl Jsp page and generates the Jsp syntax tree. There are little semantic processing here. Note that there will be 2 parsers, one for the regular jsp syntax, the other for the xml syntax. 2.3 Visitors Once the Jsp syntax tree is generated, it can be manipulated by various visitors. These visitors would use the visitor pattern, so that it only needs to define the actions on the jsp elements it has interest on. 2.3.1 The validator visitor Performs checking (e.g. allowed attribute values) on Jsp elements, and report errors. 2.3.2 The dump visitor Dumps the tree for debugging. Callable from the debugger. 2.3.3 The optimize visitors These optional phases can be added later. I have some ideas. 2.3.4 Xml output visitor Generates xml file only if needed. 2.3.5 Java code generator visitors Generates the Java program. 3. Current status I have been experimenting with Jsp syntax tree class definitions. Nothing working yet. I'll publish some code if there are interest. Comments are welcome. Also let me know if there are interests in helping, either in design or implementation. Thanks! -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
