Java + Scripting languages（JSR 223）

私はスクリプト言語APIに取り付けるフレームワークを設計しています。これは、多用途で使いやすくするためです。 JRuby、Jython、Rhino（JavaScript）のような言語では、よく使われる多くのスクリプト言語のためのインタプリタがあります。私が読んだ限り、それらのすべてはJava Scripting language APIを実装してJavaアプリケーションに埋め込みます。Java + Scripting languages（JSR 223）

このように実行した経験はありますか？私は特に、例えば連想配列（またはJava Bean）を使用します。パフォーマンス（CGIのようなアプローチやネイティブJavaの方法と比較して）のパフォーマンスはどうですか？異なるインタープリター間で切り替えるのは簡単でしょうか（もちろんAPI仕様ですが、言語固有の問題の処理方法はまだ分かりません）。

出典

2009-07-20 Daff

私はRhino、Jython、JRuby、Groovyを実行しています。それらの間には明白な言語の違いがあり、パフォーマンスは全面的にかなり遅いです。 Groovyが私のアプリケーション用にドメイン固有の言語（DSL）を作成するのが最も簡単だったことが分かりました。 Groovyはまた、パッケージのアクセシビリティとランタイム変数の点でコントロールする最も簡単な言語でしたが、JSR-223の代わりにGroovy APIを使用する必要がありました。

私はGroovy tooling/documenation/apiのメッシュがJVMでうまくいっているように感じていますが、確かにruby/pythonはかなり次のような構文を持っています。最終的には、あなたの枠組みの中でそれらを試してみることにしました。複数のスクリプト言語がうまく聞こえるが、デバッグ/サポート/トランジションの頭痛になるかもしれない。

BeanShellをチェックすることができます

出典

2009-07-20 18:24:52 basszero

ありがとうございました。私は、複数の言語をサポートすることは面倒であり、とにかく（すでにGrailsは既に私が使用しようとしている機能の一部を提供しているため）Groovyを既に目の当たりにしていたことに同意します。しかし、他のインタープリターはかなり遅いと言いますから、JSR-223の候補より前にGroovy APIを試してみます。 – Daff

間違ってはいけません。すべてのスクリプト言語は遅いですが、おそらく速度のために1つを選択していない可能性があります。 – basszero

理にかなっているし、もちろんそれは時間と快適さのトレードオフです。しかし、どのようなスクリプト言語も、ユーザビリティ上の理由からフレームワークに利益をもたらすでしょう。 – Daff

Java + Scripting languages（JSR 223）

答えて

関連する問題