因为SUN在java.web上的取向采用了向非专业人员倾斜的策略，而丢弃了java语言本身面向抽象对象的特点，反而在 presentationLayer上模仿由整个操作系统控件支持的简单的asp脚本效果；十足的弱智行为。因此写了一份批评文章选择jsp而不是servlet作为BS前台主流方案是JAVA的战略性方向错误。 看来，没有骂错！当进一步尝试采用jsp2.0的其他“新”特性时，进一步发现jsp的发展策略已经达到了极限；在较大的工程中采用jsp技术，一定要有 相应的策略技巧，否则应用程序甚至面临无法发布的困境——在开发和测试环境似乎是OK的，但一发布就无法达到平稳运行（所有jsp已经自动编译成 servlet)的程度。无法有点夸张，但让服务器down几十次过几天才算完成是有可能出现的，取决于你的系统有多大，concurrent有多少。
在几年前开始接触jsp时，一位开发人员非常兴奋地说：“jsp真方便，不用写class了，把代码写到jsp里，一刷新就出结果了”。时人也认为这是 java技术的伟大进步。本人却是不以为然，相反，我认为这是sun公司的那位白痴头头主导的一场重大退步——把java降格为脚本语言了——事实上后来 连名称也是如此:javalet。实际上对于程序员来说，javac并不是一个困难，就本人来说，甚至50%以上的程序是自已写的调用 System.compile方法自动按预设定完成编写编译和发布的程序，SUN要做的事情很多，没有必要花精力在这些地方拍马屁。
这种奉迎初级程序员的方法似乎在开发简单程序时的确是方便了，但付出了在发布、和维护上的重大代价；以后，SUN的java社团在这条方向目的混乱的路上 似乎是渐行渐远，仿佛是一条不归路了。为了克服jsp中被降格为脚本的java所带来的界面混乱，sun先是开发了一套bean的使用方式；这套今天看来 简单至极的初级反射工具并不能把主要的逻辑方法有效地组织起来；随后，sun再次开发了标签技术。应该说，这是SUN在jsp发展路上意义最重大之一的突 破，看来有可能把javalet在被强行请进html中以后再强行把它驱逐出去了。
但是，现在我发现它的问题仍是大大的。 尽管就java技术圈内，笔者是最不感冒jsp的一类，但实际上，对于jsp技术的采用深度和广度，相信却比绝大部分jsp的绝对fans要深得多广得 多。基本上是所有现存的技术已经试用过，并在实际中应用过了。如果不是把亲身感受过它的开发中的优点，笔者是不会对一样技术加以评论的，象asp，笔者几 年前开发过几万行的程序，几年没有碰了，尽管印象比jsp差得多，但近来没有碰，就不便加以评价了。也正是由于用得深，用得新，所以发现的问题才觉得特别 多。按一般经验，此山望着彼山高，真要用到其他解决方案时，只怕也同样会有火冒三丈的时侯。
写<选择jsp而不是servlet作为BS前台主流方案是JAVA的战略性方向错误> 最恼火的是因为jsp的确难以形成一个可复用的顶级模板，这样就不得不使用不同的jsp带公共的逻辑。（用惯servlet后总是对servlet可以作 为一个公共模板，大大节约了代码量怀念非常——struts中的ActionSevlet就可以看作是这样的模板，从中可以看出这种模板的作用）。最终的 办法是使用一个自动发布jsp(生成jsp)的程序把基本模板中的十来个jsp文件更替变量和模块，发布到逻辑相似的各个子应用，如科室、子公司栏目中； 这样开发和维护工作就集中到这十几个文件和调用的所有class/bean/entity中；工作量毕竟是可以控制了。自动发布的工具好处是痛快，哗拉哗 拉就完成了几十上百个目录中的jsp的编写，十几秒吧；坏处是不知不觉中形成了近千个的复杂的jsp文件；几一个连锁单位一个目录，目录下有子目录，有前 台有后台；这样百乘千，就为后来的大问题打下了伏笔。
另一个伏笔是jsp中对标签更改的处理。jsp2.0中对标签的处理方式不知是由于一个什么样的bug

事情是从上个月开始，总是在开发环境