jsp编译进程

jsp编译过程
j2ee规范中对jsp的编译有个规范：第一步，先编译出来一个xml文件, 第二部再从这个xml文件编译为一个java文件
例如: test.jsp

    <%!
        int a = 1;
        private String sayHello(){return "hello";}
    %>
    <%
        int a = 1;
    %>
    <h1>Hello World</h1> 

第一步，先编译为一个xml文件，结果如下

    <jsp:declare>
    int a = 1;
    private String sayHello(){return "hello";}
    </jsp:declare>
    <jsp:scriptlet>
    int a = 1;
    </jsp:scriptlet>
    <h1>Hello World</h1>

第二步，再编译为一个java文件, 大致结果如下

    public class _xxx_test{
        int a = 1;
        private String sayHello(){return "hello";}

        public void _jspService(HttpServletRequest request, HttpServletResponse response)
        throws IOException, ServletException{

            JspWriter out = xxxx.getWriter();
            // 创建其他的隐含对象

            int a = 1;
            out.write("<h1>Hello World</h1>");

            // 释放资源
        }
    }

从中可以看出编译过程, 编译器依次读入文本, 遇到<%@就认为这是个jsp指令, 指令是对编译和执行这个jsp生效的.
当遇到<%!它的时候就认为这是个声明, 其中的内容会直接生成为类的类属性或者类方法, 这个看里面是怎么写的,
例如: int a = 1； 就认为这是个类属性.

当遇到<%它的时候就认为这是个脚本, 会被放置到默认的方法里面的.

以上是jsp的编译过程, 还没有说对标签怎么编译, 后面再说.

有个问题, 当编译器遇到<%的时候，会依次读入后续内容直到遇到%>， 如果里面的java代码里面包含了个字符串，这个字符串的内容是%>，怎么办？
我知道的是像tomcat是不会处理这种情况的，也就是说jsp的编译器并不做语法检查, 只解析字符串, 上面的这种情况编译出来的结果就是错的了，下一步再编译为class文件的时候就会报未结束的字符常量. 例如:

<%
    String s = "test%>"
%>

编译出来的结果大致如下:

    public class _xxx_test{
        public void _jspService(HttpServletRequest request, HttpServletResponse response)
        throws IOException, ServletException{
            JspWriter out = xxxx.getWriter();

            // 创建其他的隐含对象

            String s = "test
            out.write("\"\r\n%>");

            // 释放资源
            }
    }

j2ee规范还定义了jsp可以使用xml语法编写, 因为jsp是先编译为xml, 其实<%也是先编译成了<jsp:scriptlet>因此下面的两个文件是等效的:
文件1:

<%
    int a = 1;
%>

文件2:

<jsp:scriptlet>int a = 1;</jsp:scriptlet>

不过对于规范，不同的容器在实现的时候并不一定会按照规范来做，我知道的是tomcat是按照这个来做的，并且我记得在tomcat的早期版本中还能在work目录中找到对应的xml文件.
但是websphere是不支持的，不知道现在的版本支不支持, resin好像也不支持， 也就是说在websphere中, <%必须写成<%, 不能用<jsp:script>
websphere并没有先编译为xml， 再编译为java

以上的编译过程对于编码来说是很简单的，如果不编译为xml文件，它简单到只用正则就能搞定.

EL表达式
对于el表达式的支持也很简单, 遇到${, 就开始读入, 直到遇到}, 将其中的内容生成为一个表达式对象, 直接调用该表达式的write方法即可, 例如:
abc${user.name}123

编译结果大致如下：

    public class _xxx_test{
        public void _jspService(HttpServletRequest request, HttpServletResponse response)
        throws IOException, ServletException{
            JspWriter out = xxxx.getWriter();
            ExprEnv exprEnv = xxx.create();

            out.write("abc");
            org.xxx.xxx.Expr _expr_xxx = xxx.createExpr("${user.name}");
            _expr_xxx.write(out, exprEnv);
            out.write("123\r\n");
        }
    }

不同的容器在实现的时候有所不同, 例如resin, 会将所有的表达式编译为类的静态变量, 以提升性能. 因为一个jsp页面一旦写好, 表达式的数目和内容是确定的，
因此是可以编译为静态变量的.

为什么要编译为调用表达式的write方法, 而不是编译为out.write(_expr_xxx.getValue()), 我认为其中一个原因是为了表达式做null处理,任何一个表达式如果返回会空, 那么写到页面上都应该是"", 而不应该是"null"。out.write默认会将null对象转为"null"字符串写入, 如果编译为out.write(_expr_xxx.getValue()),就得 out.write((_expr_xxx.getValue() != null ? _expr_xxx.getValue() : ""));很显然这样是影响性能的, 因为如果返回结果不为null的话对表达式可能会计算两次.如果不这样做，就需要重新定义变量, 为了变量不冲突，每个地方编译器都要生成一个新的变量名, 导致最终生成的文件较大.

tag编译
对tag的编译略微麻烦，但也不复杂，这需要对源文件做html解析，但是跟一个完整的html解析器比起来，对tag的解析相对来说简单多了
只需要在遇到'<'字符的时候读出来节点名，然后在当前应用支持的标签库中去查找对应的标签类, 如果没查到，就按照上面的继续编译为out.write("<");
否则, 读入所有的属性, 创建一个标签实例, 然后根据定义的属性和标签中定义的属性，依次调用对应的setter方法, 例如：

<c:if test="${user.name == 'tom'}"><h1>a</h1></c:if>

编译结果大致为:

    Expr expr_0 = xxx.createExpr("${user.name == 'tom'}");
    Tag _tag_0 = new xxx.xxx.IfTag();

    _tag_0.setter(...);

    int _tag_flag_0 = _tag_0.doStartTag();

    if(_tag_flag_0 != SKIP_BODY)
    {
        while(true)
        {
            // doInitBody, doBody等
            _tag_flag_0 = _tag_0.doAfterBody();

            if(_tag_flag_0 != EVAL_BODY_AGAIN)
            {
                break;
            }
        }

        _tag_flag_0 = _tag_0.doEndTag();
    }

上面是一个标签运行的标准流程, 事实上对于不同的容器，编译结果区别很大，例如resin, 实际编译结果大致如下：

Expr expr_0 = xxx.createExpr("${user.name == 'tom'}");

if(expr_0.getBoolean())
{
}

很简单的编译结果, 对于j2ee核心标签库的支持除了forEach编译为了循环之外，其他的一律编译成了很简单的代码，都没有使用循环.
这一点可能是为了减小编译结果，并且提升性能。
因为对于大部分标签来说实在没有必要按照标准的tag执行流程来编译, 对于核心标签库中定义的标签因为行为很明确，所以可以简化编译结果.
tomcat对于标签的编译, 采用的是每个标签都编译为一个方法, 并且采用的是do...while结构. resin则都编译在_jspService方法内.

标签的结束, 在编译标签的过程中，如何知道标签结束了呢？一个很简单的想法是，如果遇到开始标签，就一直读入，直到遇到结束标签，很显然这样是行不通的。
因为标签有嵌套，如果遇到嵌套标签怎么办？按照上面的流程接着读啊，读到子标签结束, 再然后呢? 稍微懂点数据结构的话，就很容易了，用栈。
同样的问题，大致的解决思路都是一样的, 比如计算器， 比如html,xml解析器, 都可以这么做， 对于html解析器，我将会写另外一篇文章专门说明.
先建立一个栈, 当遇到一个标签的时候，就先把它压入栈, 元素内容根据需要自己定义, 我们暂时假定结构如下：

class TagInfo{
    // 节点的名称
    String nodeName;

    // 节点属性 例如: test: ${user.name == 'tom'}
    Map<String, String> attributes;

    // 当前标签可能需要用到的变量列表, 例如 flagName: _flag_0, exprName: expr_0等
    Map<String, String> variables;
}

注意是把TagInfo压入栈

当遇到一个结束标签的时候, 取得结束标签的nodeName, 然后从栈弹出一个元素, 如果tagInfo.nodeName == nodeName, 那么生成该标签结束的代码
对于标签的标准流程来说，只需要生成如下的代码就可以了：

            // out.write("<h1>1</h1>");
            // 这之前的代码可能都是out.write之类的
            // _tag_flag_0之类的变量都从tagInfo获取
            _tag_flag_0 = _tag_0.doAfterBody();

            // doAfterBody等

            if(_tag_flag_0 != EVAL_BODY_AGAIN)
            {
                break;
            }
        }
        _tag_flag_0 = _tag_0.doEndTag();
    }

如果当前nodeName != tagInfo.nodeName那么就继续弹, 直到找到一个对应的标签, 其实这种情况只是容错处理,
实际上页面最后运行出来的结果跟jsp编写者的预期是不一致的.
如果一直到栈底都没找到，那就抛异常吧。

对于栈来说，很多时候不需要pop, 只需要查看一下栈顶是否符合要求，符合的时候才pop, 否则先pop, 不符合还得push, 很麻烦
所以栈最好提供一个peek函数, 传入一个int, 默认是栈顶, 根据参数决定返回当前栈的那个元素, 这样比较方便

最后, 在jsp中，规范规定, 所有以_jsp开头的变量都不能使用, 这是留给API或者容器用的.

上面是对jsp编译过程的一个分析，对于j2ee规范定义的部分，我没有看过原文，是从一些java书上看的一些零散的东西, 更多的是
看一些容器编译出来的java源文件分析和猜测的，可能很多地方的想法跟j2ee规范定义的不一致，有兴趣的可以在java官网找一下
规范原文看看。

06年的时候，我曾经用java实现过一套类似于tomcat的容器，当然功能弱多了, 只支持一些基本的功能，能跑jsp和servlet, 不支持el和tag.
当时刚工作，对于一个代码量较大的项目的控制能力很差，写到最后觉得架构上很力不从心，勉勉强强能把jsp和servlet跑起来之后就没有再继续了。
当时还不了解socket的nio, socket的io用的是阻塞io, 线程也没有用线程池，每次都是new一个新线程，性能很差。
有兴趣的可以参考我的另外几篇文章，用java实现反向代理, 其中的代码是当年代码中的一部分.

说一说js版的jstl吧
js版的jstl基本上是按照我上面分析的来实现的， 支持脚本, 支持el, 支持tag, 支持自定义tag.
为了性能的考虑，对tag的编译借鉴了resin的思路, 对于标准标签不按照标准流程编译, 而是精简编译.
还是出于性能的考虑，编译过程省略了中间一步，也就是不先编译为xml, 而是直接编译为js源文件.
因为如果编译过程产生xml, 对于大文件来说就要在内存中再产生一份xml的内容, 然后再次编译为js文件
中间需要两次编译，耗内存还耗资源.

对el的支持，采用了一个偷懒的方法. 例如abc{user.name}123这样的代码, 在jstl的实现中，需要写成: abc{this.user.name}123
只要是pageContext中的属性都需要加上this；
这跟实现有关, 对el如何计算是很麻烦的, 需要写一个解释器, 否则简单的解析对于复杂的表达式就无能为力了.
例如${user.name}很容易计算出来结果, 但是对于${myfun1(user.name) + myfun2('test') + myfun3('test')}这样的表达式
或者是%{user.age > 100 * 2}就比较麻烦了, 没有一个解释器基本搞不定.
我一开始考虑用eval, 但是eval在某些环境中性能较差, 而且编译出来的结果里面如果有很多el就会调用很多次
更重要的是用eval也无法实现, 例如, eval("user.name + '123'"); 在全局中根本没有user这个对象
但是如果都加上this, 那么eval就可以了

但是绝对不能用eval, eval的开销太大.
写个解释器不现实，也没必要，为了支持表达式，用一个解释型的语言再写个解释器，不太划算。
最后采用了一个折中的办法，就是pageContext中的对象, 在el中都加this, 也就是说el中的所有的this都指向pageContext
对于每一个表达式都生成一个表达式对象，这点和j2ee中的定义保持一致. 另外会生成一个函数, 例如:
abc${this.user.name}123

最后的编译结果大致如下：

new (function(){
this.service = function(pageContext){
    var out = this.getWriter();
    out.write("abc");
    this._expr_0.write(out, pageContext);
    out.write("123");
})();

// 这里是编译过程产生的所有的表达式对象

this._expr_0 = new Expression("_expr_0", "this.user.name");

// 这里记录了编译过程产生的所有的表达式对象的引用

this.exprPool = [
    this._expr_0
];

// 这个地方对关键，是所有的表达式函数, 目前为null, 在第一次运行的时候才会被编译
this.exprList = null;

第一次运行的时候，会检查this.exprList是否为空, 如果为空，编译所有的表达式, 编译结果如下：

this.exprList = new (function(){
    this._expr_0 = function(){
        // 最终this._expr_0函数会被放到pageContext中, 这就是为什么要用this的原因
        return ( this.user.name );
    }
})();

this.exprList指向的是一个新的对象, 这里必须是个对象才行。
下一步，运行期：

scriptlet.execute(context);
context由调用者传入, 可以是一个纯粹的json对象. scriptlet.execute方法如下：
// scriptlet指向了第一次编译返回的对象
// scriptlet在new的时候创建了execute方法
scriptlet.execute = function(context){
    var pageContext = PageContextFactory.create(this, context, this.exprList);
    this.handle(pageContext);
};

在PageContextFactory.create方法里面会对context包装， 创建一个新的对象，并把context的所有属性赋给新的pageContext
然后再把exprList包含的所有的函数赋值给新的pageContext, 这样pageContext就拥有了context的所有属性和scriptlet运行所
需要的所有的表达式函数, 表达式中的this指向的是pageContext, 这就是el中为什么要用this的原因.