Java脚本技术应用实例

Java可以支持脚本语言,可以带来很大的便捷性,很有价值！

C发明于1972年，知识分子们还在上山下乡，众多的javaeyer还没有出生，现在还不是有大量相关的书籍，文章发表？
Java发明于1991年，改革开放才刚刚真正的开始，众多的javaeyer还没见过计算机，现在还不是天天有相关的文章在出现？
2011年怎么了？呵呵。

如果是纯解释的话，效率的确很低，但是Java脚本框架中提供CompiledScript接口，如果脚本引擎实现该接口，则可以将脚本预先编译，效率就基本没有问题了。这有点像JDBC中的PreparedStatement，效率就没什么问题了。

还是不够高

虽然可以编译，但它的执行比java慢的不是一个数量级

在很多工作流产品中， 都拿rhino来做迁移的判断以及前后置脚本的执行，在高并发情况下，java执行只要几十或者几百毫秒的时候，js要2秒左右

并且，编译会带来一个问题

有许多js脚本是通过java代码生成的，这就意味着生成的js的长度在某些情况下会很长，当超过64k的时候，编译会失败的

http://hi.baidu.com/freish/blog/item/5d02e450f4dbf24e1138c2ed.html

第一次看到插件方面的文章，谢谢分享

遇到高并发这种情况，我没有做过实验，可能确实效率较低。毕竟，可能会有诸如校验，类型转换之类的动作，这个我下来再看看。就一般应用(并非服务器如httpd之类)而言，如编辑器，浏览器，IDE等，脚本作为插件的形式存在于应用程序的生命周期中，不会涉及到高并发这类的需求。如果是freish兄所说的这种情况，通常会把代码编译成动态库(C)或者可供虚拟机直接执行的bytecode(Java), 脚本语言本身则无法做到。

确实会有此类的问题，这个在之前的项目中遇到过：一个开发人员将JSP文件写的非常大，业务逻辑(很多的条件判断等代码)全部都写在JSP中，最后生成Servlet的时候，超出了方法的长度限制。不过我认为这种情况可以通过设计来避免，比如类/方法的拆分等。也就是说，这并非引擎有什么问题，比如，你手工的将一个Java方法写的超过64k，同样会有这样的问题。

复杂脚本毫无问题，前年一个项目，业务规则就是用JS写的，跑Rhino

动态脚本确实效率比较低，顾此失彼