es5とes6とjs1.8.5と

nashornがrhinoを置き換え可能なパフォーマンスになったとはいえ、es5とjs1.8.5は全く別の言語なので互換性は低いです。es6と比べると更に低くなります。
さらにjs1.8.5の言語機能はes2016相当(2016からmodulesとclassesと小さな違いを引いた感じ)なのでjsの方がまだ未来に居ます。そのため、js1.8.5の実装であるrhinoで出来ていたことのすべてをnashornで置き換えることは出来ません。たとえnshornがes6をすべて実装したとしてもです。

このようにjsとesには小さな仕様の差異だけでなく言語機能の大きな差異もあります。

また、rhinoとnashornのECMA-262以外の仕様や固有APIの違いもあります。とくにrhinoはjavaとの通信にnetscapeで伝統的なliveconnectをサポートしていますが、nashronはそれをサポートしていません。しかし、にも関わらず、javaとの通信のための構文拡張やAPIのデザインが良く似ています。これらには互換性がないので以降の際には注意が必要です。

以上のようにjavaでは強制的にrhinoがnashornに置き換わりましたが、互換性はほとんどないと言っても過言ではないので、移行する時は上で上げた二点に関して十分に注意しましょう。

jdk 9-ea+111

ea+111でmodule絡みの初期のmergeが行われました。
これでjdk eaでmodule周りが利用できるようになりました。jigsawはまだ変更されるらしいので最新の状況はjigsaw eaを追う必要があります。

jdk eaがモジュール化されたことによりexportされていないinternal apiをリンクできなくなります。
Unsafeは必要な物は標準化される予定ですが、それ以外のnashornやjavafxはどうなるんでしょう?ここらへん追いかけていないのでよくわかりません。

それとnashornに関連して、jdk9でrhinoでsun-spiderを走らせた所、JVM自身がまた遅くなっていましたがnashornは速くなっていました。おそらく、JVMの遅さはmodule周りの読み込みの分だと思いますが、それを差し引くとnashorn自体が速くなっていることになります。

jdk9のnashornはついにjava8上のrhino並になりました。VMが遅いせいでjdk9上のrhinoはjava8比10%程度遅くなっているのでjava9上ではnashornはrhinoより更に速いということになります。つまり、ようやくnashornがrhinoを置き換え可能なレベルに達したということです。

babel疲れた。

node遅いデカイ。babelプラグイン地獄の果てにたどり着いたら文字列の末尾バックスラッシュ使ったコードがおかしい上に
"mutating the [[Prototype]] of an object will cause your code to run very slowly; instead create the object with the correct initial [[Prototype]] value using Object.create"を出しやがった。
array subtypingが必要なコードは書いてないはずだから__proto__の使い方間違えたな!コンチクショウ!

もう自分用のトランスレータ書こう。