吉里吉里2をJavaへ移植しAndroidやJavaアプリ/アプレット(Win/Mac OS X/Linux)で動かすためのプロジェクトです。 オリジナルは吉里吉里2です。
現在、TJS2 の移植実装が完了し、テストフェーズになっています。 TJS2 スクリプトを本ソフトウェアで動作させることは出来ますが、不具合を含んでいます。
現状、TJS2 の基本的な部分についてのテストはパスしましたが、組み込みクラスのテストは未完了です。 初期実装において気付いた問題点や修正することが好ましいと思われる項目の修正をテストスクリプトを通しながら進めています。 これらの作業が完了すれば Java版 TJS2 の初期バージョンは完了です。 その後、吉里吉里2のエンジン部分の実装に移ります。
final がつけられるところはつける。
hint は String.hashCode を使うことで不要になると思われるため削除しました。 ベンチマーク結果は少し向上したようです。
ディスアセンブラとコンパイラとVMが一つのクラスになっているので、これは3つに分けた方が良さそう。
Token を private へ移動した方がより効率的か？
StringStream で char[] で持っているものは、CharBuffer にした方が効率的か？ その場合、範囲チェックの例外を補足している関数があるので、そこの修正も必要。
String.sprintf は Java の String.format で実装しているが、Java の場合は型がより厳密に判定されてしまう。 TJS2 は Variant 型なので適切な型へ変換して書式指定を展開するようにした方が良さそう。
Date のパーサーは DateFormat 任せ。 "年/月/日 時:分:秒" 形式は (0-9+)\\/(0-9+)\\/(0-9+)[ \t]+(0-9+):(0-9+):(0-9+) で判定。 am/pm とかその辺りの判定していない。 テスト必須。
Variant の Integer が 32bit で実装しているけど、問題出たりするかな？ Date.getTime/setTime で問題が出てくるかな？ もともと time_t でlongか。 Math.RandomGenerator の random63 と random64 が random32 と同じになってしまっている。 random32 は、INT_MAX 越えの値の場合、マイナスにして幅を確保している(dateも同じ)。 ディスク容量が2TBを超えたときに問題が出る。 Long (64bit) へ書き換えるべきかどうか検討の必要あり。
new を多用しているのでオブジェクトプールを利用した実装に書き換えるべきかもしれない。 ただ、Variant 等は削除タイミングが管理できないケースもある。 オリジナルではリファレンスカウンタを使っているが…… 出来る範囲内で、オブジェクトプールを使い最適化するのがいいかもしれない。
NativeFunction クラス実装忘れてた。
Java の組み込みソートの都合上 Array のソートは常に安定ソートになっている。
メモリ管理は Java 任せなので、finalize の呼び出しタイミングが異なると思われる。
後は、結果が異なるようなら修正するつもりのものとして、String.sprintf が Java の String.format で実装されていることから書式指定が異なるかもしれない。 オリジナルの正規表現は boost のものになっているが、Java 版は組み込みの正規表現で実装している。 Date のパーサーは DateFormat 任せになっている。
構文解析器は、完全に別実装だけど、ここはオリジナルと同じように動作するようにする。 ただ、これによってエラーメッセージは少し親切に出力できるようになる。
NativeClass は、各種メソッドを NativeClassMethod に格納して、自身のプロパティに入れる。 new されたとき、対象のオブジェクトにプロパティ内の NativeClassMethod を全てコピーする new されたオブジェクトは、関数コール時に自身のプロパティを検索して、該当の関数 NativeClassMethod の funcCall を呼び出し、NativeClass (継承したクラス) のメソッドを呼び出す。
Java のクラスを TJS2 に手軽にバインドする為のクラス群 ( NativeJavaClass / NativeJavaClassConstructor / NativeJavaClassMethod / NativeJavaClassProperty / NativeJavaInstance ) はまだ動作確認していない。
CustomObject の Symbol を HashMap に書き換える。 → HashMap にしたらパフォーマンスが低下したので、現在の実装のままにすることにする。
オブジェクトプールを使うと少しパフォーマンスが低下した。 Android では傾向が異なるかもしれない。
edit