Java + 脚本语言 (JSR 223)答案

【问题标题】：Java + Scripting languages (JSR 223)Java + 脚本语言 (JSR 223)
【发布时间】：2010-11-12 09:43:45
【问题描述】：

我正在设计一个框架，我想将它附加到脚本语言 API 以使其更通用和更易于使用（对于某些事情，我自己真的更喜欢脚本方式；）。对于 JRuby、Jython 或 Rhino (JavaScript) 等语言，有许多流行的脚本语言可用的解释器，据我所知，它们都实现了 Java Scripting language API 以将它们嵌入到您的 Java 应用程序中。

您有以这种方式运行它的经验吗？我对处理例如特别感兴趣关联数组（或 Java Bean）。性能如何（例如，与类似 CGI 的方法或本机 Java 方式相比）？在不同的解释器之间切换是否容易（当然这是一个 API 规范，但我仍然不知道如何处理特定于语言的问题）？

【问题讨论】：

标签： java api scripting

【解决方案1】：

我运行过 Rhino、Jython、JRuby 和 Groovy。它们之间存在明显的语言差异，并且整体性能相当缓慢。我发现 Groovy 是为我的应用程序创建领域特定语言 (DSL) 的最简单方法。 Groovy 在包可访问性和运行时变量方面也是最容易控制的语言，但需要使用 Groovy API 而不是 JSR-223 来完成。

我觉得 Groovy 工具/文档/api 与 JVM 的结合更好，但 ruby/python 肯定有很多追随者，而且语法可能对某些人来说更舒服。最终，我会在您的框架中全部尝试并选择一个。多种脚本语言听起来不错，但调试/支持/转换可能会让人头疼。

之后：您可以检查 BeanShell

【讨论】：

感谢您的意见。我同意支持多种语言会很麻烦，而且我已经在关注 Groovy（尤其是因为 Grails 已经提供了一些我打算使用的功能）。但既然你说其他解释器很慢，我会在 JSR-223 候选者之前尝试 Groovy API。
别误会，所有的脚本语言都很慢，但你可能不会为了速度而选择一种
嗯，明白了。有道理，当然这是时间/舒适度的权衡。但出于可用性原因，任何脚本语言都会使框架受益。