SwingプロジェクトのJavaFXへの移行を開始しますか
Swing + SwingXで書かれた4年前のプロジェクトがあります。現在、それはまだ生きていて、まだキックしています。
しかし、GUI関連の機能のリクエスト（ソート可能なツリーテーブルなど）が増えるにつれ、リクエストを処理するのが難しくなってきたように感じます。 SwingXプロジェクトを取り巻く活発な開発が行われていないため、これは特に当てはまります。
また、私は良いものをほとんど見つけることができませんが、積極的に維持/開発/進化するGUI Javaフレームワーク。
Swingの開発者の誰かが同じことを感じているのでしょうか。 SwingプロジェクトをJavaFXなどのよりアクティブな開発済みGUIフレームワークに移行し始めましたか？
私は個人的にJavaFXに移動します（2.1+、厄介なスクリプト言語を備えた古い奇妙な1.xバージョンではありません）。新しいJavaFXは100％完璧というわけではありませんが、Swingを使用するよりもはるかに楽しいものです。私は（特に組み込みのWebkitエンジンを考えると）その妥当な将来を考えています。
私はよく同じことを自問しますが、既存のプロジェクトをJavaFXに移行することはないと思います。少なくとも今のところ、中規模から大規模のプロジェクトには適していません。ただし、新しいプロジェクトではJavaFXを検討し、将来の移行についても検討し、JavaFXの進捗状況に基づいて質問を再評価します。
現時点では、私の懸念は次のとおりです。
未成熟
はい、まもなく3.0に移行しますが、これほど長くは続かず、まだ大きな変更が行われています。したがって、リスクを回避する大規模な企業向けソフトウェアの場合、これは比較的痛手スポットです。
パフォーマンス
パフォーマンスの違いに関する十分なハードデータを見ていません。
ウィジェットとコンポーネント
新しいコンポーネントで十分なゲインが得られていません。これは未熟に関係していると思います。 Swingとは対照的に、それらをどれだけ拡張および合成できるかについても、まだわかりません。
全体として、JavaFXに完全に納得してもらうには、利点に関するハードデータが欠けていると思います。
一方、Swingは実証済みでテスト済みです。はい、APIは不格好で、JTextPaneのようなSwingオブジェクトでIDEのオートコンプリートを呼び出すと、ママのために泣き泣きますが、十分な知識がある場合は、 Swingを使用して優れたUIを構築し、パフォーマンスが優れている（私はSwingのパフォーマンスが悪いという誤解を買ったことはありません。SunのブログでRomain Guyの以前のブログ投稿を参照してください）と、かなりきちんとしたことができます。
したがって、何かを切り替える前に、まず小さなプロトタイプを試し、アプリケーションのダイアログの一部を移植して、それがどうなるかを確認することをお勧めします。
私は現在多くのJavaFXを行っており、Swingよりもそれを好みます。シーングラフの構造は、Swingで慣れているものとは異なりますが、大幅に改善されています。 APIは操作するのが楽しく、さわやかです。
マルチメディア、アニメーション、Webブラウジングなど、さまざまなことができます。たとえば、数行のコードで Google Mapsアプリケーション を作成し、html5とJavaScriptを埋め込むことができます。
これは、Java 8ランタイムに含まれていると言われています。これは、デフォルトのuiフレームワークとしてのSwingの明確な置き換えとして意味されます。
@ Migration：まず、JavaFXに変換できるアプリケーションの部分を分離する必要があります。 Swing-JavaFX 2の相互運用性は重要です。javafx.embed.swing.JFXPanelを使用してJavaFX要素を埋め込むことができます。 swing-fx-interoperability を参照してください。 （完全を期すために、SWTに組み込むこともできます。）
Swingはレガシーテクノロジーになりつつあります。しかし、それが何をするかについては非常に良好であり、予見可能な将来にはなくなることはないので、特にすでに投資している場合は、それから離れる理由はないと思います。 JIDEソフトウェア は、標準のSwingに欠けているものを置き換える（商用の）Swingコンポーネントを作成します。たとえば、並べ替え可能なツリーテーブルは Grids にあります。
新しいJavaFXバージョンは非常に印象的ですが、GUIの完全なオーバーホールに多くの時間/労力/お金を費やす意思がない限り、完全な移行を行う価値はないと思います。
Swingには奇妙な点があり、その年齢を示していますが、いくつかの利点もあります。
- 非常に強力なクロスプラットフォーム機能、現在はJavaFXよりもはるかに優れています
- 成熟しており、JavaFXよりもはるかに優れている
- 大規模なユーザーコミュニティ/ライブラリエコシステムがある
- おそらくあなたはすでに多くのSwingスキルを持っているか、それらを使って簡単に人々を雇うことができます
最終的に、それが壊れていない場合、なぜそれを修正するのですか？
もちろん、新しいプロジェクトの場合、JavaFX、Androidおよび/またはWebベースのGUI（おそらくVaadinのようなものを使用））を非常に真剣に検討しています。
私はOPと同じ立場にあります。レガシーSwingアプリケーションがありますが、ネイティブでサポートされていない新しいイディオムとインターフェースを実装する必要があります。これらのアプリケーションの最大のものは、さまざまな理由（モジュール性の向上、MVCとイベントディスパッチ構造の改善など）で数回リファクタリングされているため、UIコードの書き換えを完全に嫌うわけではありません。だから私はこの問題について長く考えていました。
ただし、本質的にレガシーテクノロジーであるものに多くの時間と労力を費やすことなくSwingで解決できないものもあります。たとえば、単純なマウスイベント以外の新しいタッチスクリーンデバイスは、Swing自体ではサポートされていません。 Swingベースのブラウザーコンポーネントを提供することも同様に面倒で費用がかかります。私の場合、javafx-in-swingアプローチは、重要な方法でUIイベント処理を複雑にするため、オプションではありません。
私はそれがその時代で古くて忠実だったと思います、そしてあなたのプラットフォームがあなたのコードベースと同じように変わらないなら-明らかにそれに固執してください。しかし、アプリケーションがより現代的なユースケースに進むためには、おそらくJavaFX 2+が私の場合に進む方法になるでしょう。
補足：Swingでjfxで失いたいと思っていたはずの機能の1つは、UIイベントディスパッチへの1つのスレッドからルールすべてへのアプローチです。重要なユーザーインターフェイスでは、UIの鮮明さと応答性を維持するためにマルチスレッド化が必要であり、APIのIMHOの欠点は、アプリケーション開発者が同じ落とし穴を簡単に見つけられるようにすることです。
大規模なデスクトップベースのアプリケーションで [〜＃〜] rcp [〜＃〜] を使用して素晴らしい経験をしました。それは基本的にEclipseのGUIレイヤーの抽象化として始まり、それ以来長い道のりを歩んできました。 AWTに基づくSwingの代わりに、RCPはSWTに基づくJFaceに基づいて構築されます。アプリケーションを開発し、Eclipse自体が使用するGUIの概念（ビュー、エディター、パースペクティブ、ウィザードなど）を使用できます。非常にスケーラブルであり、Eclipse自体と同様に、常に改善されています。
ただし、既存のプロジェクトをSwingからRCPに移行したことはありません。さまざまなパラダイムに頭を回すにはかなり時間がかかると思います。モデルとビューのレイヤーを適切に分離していないと、苦労することになります。しかし、ソート可能なツリーテーブルなどについて質問したので、RCPはその点で優れています。
これをさらに再検討したい場合は、Lars Vogelの tutorial を試すか、 オープンソースプロジェクト または commercialの例をいくつか参照してください。プロジェクト RCPを使用します。