- Java低速GUI Swing 10
362 ：デフォルトの名無しさん[sage]：2014/09/09(火) 09:07:08.70 ID:N9PRwLzG - javafxのlinux platformへの対応が今でも後回しってことが根本的に間違ってる
java7(javafx2)がでた2011年の時点でも、javaseやjavafxがwindows platformで使えるメリットって全く無いでしょ
そういう要不要の判断ができないのは、優先順位や目的も設定できず、なんとなくで作ってたのが原因だろう
モバイルデバイス市場をグーグルに持ってかれちゃった時点でjavafxは廃止してとりあえず様子見でswingに集中すべきだったのにね
で、できたjavafx api/frameworkはswingと全く同じだし、それならswing apiを流用して内部実装だけ取り替えるという設計もあったんじゃないのかと思う
javafx9は現在のjavafx2/8のapiを全て破棄して、swingライブラリ一部として結合してほしいね（それぐらいのことしないとjavaのguiは使ってもらえないだろう）
ただ、グーグルはオラクル（サン）に比べれば名ばかりの貢献であって、長期的に実質的にはオープンソースに何らの貢献もしてないし，グーグルはオラクルを上回る大糞ってことは確かだ
| - Java低速GUI Swing 10
363 ：デフォルトの名無しさん[sage]：2014/09/09(火) 10:36:53.39 ID:N9PRwLzG - よくみたらJComponentの継承関係がjava.awtに依存してるからjavafxとswingを統合するのは無理か
それで考えてみたんだけど、javafxのui生成はfxml,cssだけにして、javaコードではui生成はできないようにすればjavafx apiの大半を削除できるし、awt,swingとの差別化にもなる
fxmlにはannotation仕様も入るから、html+jsのようにbindingもfxmlでやれるし、現在javafx apiが肥大化し続ける問題を全て解決できるだろうね
html,cssでpage form作るのとほぼ同じパラダイムになるからswing mvcを学ばなくて済むし、コントロールのクラスが非公開なのだから公開java apiをメンテしなくて済む
uiの動的生成は全く使わないしbuilder classパターンと同じくいらないから、コントロールのjavaクラスはjava9では削除にして、fxml+annotation(java)+nashorn(js object)で構築するのが自然だろう
|
|