---
# System prepended metadata

title: PRO143 質疑応答
tags: [Tsukuba Univ, PRO143]

---

###### tags: `PRO143` `Tsukuba Univ`
# PRO143 質疑応答
- **現在のJSやTSにはclass構文が導入されているため、クラスベースのオブジェクト指向プログラミングは可能なのではないか**
    - その通りではあるが、構文上プロトタイプベースのオブジェクト指向プログラミングができてしまうため、そうすることが（仕組み上）できないJavaでの開発ができるとさらに良いと思う
    - それはコード規約などで縛ればよいのではないか
    - はい、しかしReactやvueを扱う際にはどうしてもそのようなコードを書く必要が生じてしまう
    - それではJS自体を批判するのではなく、そのようなライブラリに対して問題提起を行えばよいのではないか
    - 仰る通りだと思います
- **JVM自体をwasmで実装することは考えなかったのか**
    - 一度考えており、今後は更なる高速化を目指してwasm実装にすることを検討している
- **数値や配列をJSプリミティブな値として処理することで、doubleの演算や+0、-0の扱いなどで問題が起こるのではないか**
    - それについては仰る通りであるが、スライドで示した通り今回はオーバーヘッドの削減を目的としてこのような（Javaの仕様に厳密に準拠せず、TSに処理を一任する）実装になっている。従って、プログラマはこのような部分を仕様として認識する必要がある
- **JavaでWebサーバ上からファイルを取得するようなコードを書くことはできるのか。また、その場合非同期に取得するのか同期的に取得するのか。更に、非同期で取得する場合、そのコードはどのように書けるのか**
    - 現状ではできない。しかし、今後の実装ではできるようになる可能性がある
- **BJVMでわざわざネイティブメソッドを用意しなくとも、JSをevalする関数を用意しておけば、あらゆるDOMの機能にアクセスできるのではないか**
    - その通りではあるが、その実装だと戻り値の型が不定であるため実装は考えていない
    - そんなことはないだろう
    - ただ、戻り値を期待しない関数については効果があると思うので、今後実装を検討していく
- **ES Modulesを使わなくともhtmlにscriptタグを挿入すればほかのJSモジュールを読み込むことができるのではないか**
    - その通りではあるが、その実装だとHTMLが存在する前提でのBJVMとなってしまう。例えば、Node.jsなどへの移植などができない可能性がある。
    - しかしBJVMはDOMを扱うという性質上、HTMLの存在は必須なのでは？
    - 仰る通りである、今後そのように変更することができないか検討する
- **wide命令は配列や変数のインデックスを拡張する命令であったと記憶しているが、数値型をnumber型で扱うこととどう関連するのか**
    - これはスライドの間違いで、正しくは「内部的にはJavaの数値もインデックスも同じnumber型で扱うため、実装していない」のである
    - なるほど、しかしwide命令を実装しなければバグが出てしまう（number型は32bitでしたっけ...）のでは
    - それに関しては仰る通りであるが、コーナーケースでありまた多くの変数を用意することは困難であるためテストしていない
    - スクリプトなどで大量の変数を持つJavaコードを用意すればよいと思う
    - その通りだと思う、今後テストして、実装ができるか検討する
    - ちなみに、JSのnumber型は整数であれば52bitまで精度が保証されていた気がします
- **結局BJVMにソースを与える手段としては何があるのか**
    - 現状ではWebサーバ上においてfetch関数などを通してJVMに与える、もしくはユーザがファイルを選択するかのどちらか
- **ScalaJSなども調べ、関連研究に載せるといいと思います**
    - KotlinJSなどと似たようなものになると思うので、今後ぜひ調べてみたいと思う
- **ただJavaの機能を実装していくのではなく、対象とするJVMバージョンを決め、更にその中でも実装する機能としない機能を明確に区別すれば、今後の開発がしやすくなり、またプログラマーにとっても使える機能/使えない機能が明確になって良さそう**