この投稿の最初にJohn Rose氏はLongjumpsかJava言語内の何らかのクロージャに必要とされるかもしれない非局所脱出に関して説明(source)した。事前に配分されたスタックトレースを伴った例外処理メカニズムを使うことによって、フローコントロールの代償を支払わずに非局所脱出を得ることが可能になるのだ。実に良くできていて、これは局所脱出/返還よりも費用が3倍以上も少なくなる可能性がある。また これはマシンレベルのgoto解説に最適化されるかもしれない。これはObject.clone()を最適化する(source)Java 7構築を伴ったパフォーマンスとなる。
次にJohn氏はJVM内のテールコールに直撃(source)している。Explicit内でテール回復を縮小する機能はfashion(ハードテールコール）か、もしくはコンパイラ最適化(ソフトテールコール）として保護される。この投稿によってコメント内でアプローチと使用法に関する熱いディスカッションが繰り広げられたが、テールコールは機械言語、またはinvokedynamic(JSR-292)(source)から恩恵を受けるダイナミック言語同様に、JVM上において言語機能がついた機能を伴う言語の補助となるかもしれない。
それは他者と同様にinvokedynamicを採用するかもしれない。ハードテールコールを持っているということは、ダイナミックコールを実装するのにもっとたくさんのオプションが与えられるということだ。通常のルーティンをテールコールするディスパッチルーティンに分枝することができる。（実のところそれが、少なくとも返還値が箱入れされていなければ、java.lang.reflect.Method.invokeの作動の仕方なのである。） Schemeはダイナミック言語であるため、テールコールはJSR 292にとはあまり関連性が無い。
最後に彼はTuples(source)に注目し、2004年に提出した、アイデンティティを保持する必要のないtuple semanticを伴うpure tuple types valueクラスを説明した提案書を挙げた。これによって複数の返還値を伴うメソッドのサポートも縮小できる。再度、Java言語よりむしろJVMにおける強調がここで明確になる。
Tupleを強化された言語が、値を入力されたグループ間の標準的な変換とそれらの値を持っているたくさんのオブジェクトにリファレンスを提供する。たとえば、それぞれの値のクラスは引数がそのクラス用にタグされたクラスであるコンストラクタをサポートする傾向にある。Tupleは長さが固定されたオブジェクトアレーかラッパークラス内のプリミティブバリューを伴った 標準不変のユティリティクラスとして表されることが多い。
そして再び活気付いたコメントスレッドには下記のようなコメントがあった。
実はあなたが示しているように、Javaに値指向のタイプを統合すると難しい設計の問題が引き起こされる。この投稿で私が言いたかったのはJVMにTupleを追加するのは比較的シンプルで、言語設計の問題のソリューションを必要としないということだ。
これらのプロポーサルになにか覚えがあるだろうか？JVMがもっと他の言語をサポートするのかJava言語の進化をもっと見たくなっただろうか。それともこれは全くの平行線状にあるのだろうか。今後もInfoQにてこのトピックを追い続ける予定だ。
原文はこちらです：http://www.infoq.com/news/2007/09/jvm-longjumps-tailcalls-tuples