http://openjdk.java.net/jeps/222 をテキトーに訳した。JavaにもREPLの提案が！と一部界わいで話題になっていたので読んで見た。
JEP 222: Java Read-Eval-Print Loop (REPL)
Owner Robert Field Created 2014/05/16 23:13 Updated 2014/10/30 22:20 Type Feature Status Candidate Component tools Scope JDK Discussion compiler dash dev at openjdk dot java dot net Effort L Duration L Priority 2 Reviewed by Brian Goetz Endorsed by Brian Goetz Release 9 Issue 8043364
Summary
Javaプログラミング言語の宣言・文・式を評価するための対話的な方法を提供します。
Goals
Java Read-Eval-Print Loop (REPL) は、あるコードコンテキストにおいてJavaプログラミング言語の宣言・文・式を対話的に評価する方法を提供します。コードコンテキストは、これまでに入力したコードベース、対話的に定義あるいは修正したメソッドとクラス、REPLに入力済みの値、などから構成されます。手早く調査やコーディングを行うには、文と式をメソッドで使う必要は無く、式は副作用を持つ必要は無く、メソッドをクラスやインターフェースに含める必要はありません。ツール上で単純なテキスト入出力を処理して、より複雑な機能をビルドできます*1。
Non-Goals
GUI・デバッガのサポート・IDEライクの機能は対象外です。式・文・メソッドがトップレベルになれる点以外、サポートされる言語はJavaプログラミング言語そのものです。新しいインタラクティブな言語を作るわけではありません。
Motivation
プログラミング言語を学ぶには素早いフィードバックが重要です。教育機関が言語教育にJavaではなく他言語を採用する第一の要因として、他言語にはREPLがあり、"Hello, world!"プログラムを書くまでのハードルが低いこと、が挙げられます。Scala, Ruby, JavaScript, Haskell, Clojure, Python、これらの言語はすべてREPLがあり、プログラムを小さく始めることが可能です。
開発者がプロトタイピングコードや新しいAPIを試すためにコーディング手法を試行錯誤するのも重要です。対話的な環境はこういうケースの場合、編集・コンパイル・実行してSystem.out.printlnするよりも非常に効果的です。
class Foo { public static void main(String[] args) { ...という儀式無しに、Javaで書かれたショートスクリプトが実行可能になります。
Description
javacコンパイラやjavacコンポーネント上に構築されたツールは、コンパイルコンテキストを保持しつつ、式や文の粒度でコードを生成する必要があります。パーサーは、クラス・フィールド・メソッド・文・式がトップレベルになれるような拡張を受け入れる必要があります。ひとまとまりのコードに関しては単純なコードラッピングで実現可能ですが、真に対話的にするには、恐らくより深いレベルでの統合が要求されるでしょう。よって、コンパイラAPIの拡張が望ましいです。対話的な評価には特殊なコード生成が必要で、たとえばmapのような寿命の長いデータ構造の変数の格納用のコード生成などが例として挙げられます。
実行時の対話的な更新は、クラスローダーやクラス再定義、もしくはその両方を利用可能です。*2。
他の選択肢としては、おそらくjavacコンポーネント上に構築される対話サポートのためのインタープリターを使うことです*3。
Alternatives
第一の代替案としては、対話的な更新機能の無いbatch scripting wrapperを提供することです。これが最初のステップになると思われます。
もう一つの代替案は現状維持です。別の言語にしたり、BeanShellなどのサードパーティーREPLを使います。ただし、モノによってはJDK1.3ベースのまま数年間開発が止まっていたり、言語に独自拡張が加えられていたりします。
多くのIDEのツール、たとえばNetBeans debuggerやBlueJ's CodePadなどは、インタラクティブな式評価機能を備えています。Preserved contextとコードはクラスベースのままで、メソッド粒度は未サポートです。これらのツールは独自拡張を施したパーサー／インタプリターを使用しています*4。
Testing
REPLは入出力ベースのものなので、テストの構築は直感的であるべきです。既存のテストからスクリプティングのテストを生成出来ます。
Risks and Assumptions
完全な対話的な更新機能が、実装するには現実的には複雑すぎるという困難が判明するかもしれず、結果として、更新機能に制限が生まれるかもしれません。最悪の撤退ケースとしてはbatch scripting supportのみのサポートになることです。
Dependences
今のところ依存するものはありません。もしJEP 159が実装されていたら取り入れます。
*1:The tool will handle simple text input/output allowing others to build more complex functionality on top of it.が原文。othersとitが何を指しているのか自信ない。入出力とツールじゃないのかなぁ？
*2:Run-time interactive updates could be based on class loaders, class redefinition, or both.が原文。could be based onがどうも上手く訳せず…対話的で更新を伴う操作はクラスローダーとかクラス再定義とかの土台の上に構築可能ですよ、という意味合いだとは思うが。
*3:Another option would be to use an interpreter for interactive support, presumably one built on javac componentsが原文。イマイチ訳に自信がない。実現方法として、コンパイラAPIの拡張がまず第一案で、javac上に構築されたツールを使うという第二案もあるよ、という意味合いだとは思うけど。
*4: They use specially crafted parsers/interpreters.が原文。craftedなんで、hackといいますか、職人の気合で作ったものみたいなニュアンスが含まれていると思われる。このJEPは、javacの上にそういうツールを作って解決するんじゃなくて、コンパイラに手を加えちまおうぜっていう提案なので、訳文は「独自拡張」というやや否定的なアトモスフィアの単語にしてみた。
