java - JIDEに関するフィードバックを探しています

Question

かなり大きなJavaベースのデスクトップアプリケーションの開発を始めようとしています。JIDEコンポーネントとフレームワークを見た後、それは一見良い解決策のようです。それらの製品をご利用いただいた方からのご意見をお待ちしております。それらはどれくらい信頼できますか？学習曲線は何ですか？長所と短所？

Answer 1

私はJIDEを2年近く生きて呼吸してきました。私の会社のSwingGUIアプリの主な開発者として、JIDEは私の人生をより簡単でより困難なものにしてくれました。

まず、良い部分です。

そのコンポーネントの幅と深さは信じられないほどです。最新のデモには171個のアイテムがあり、そのほとんどはさまざまなコンポーネント用です。それはSwingがすべきだったものです。会社は確かに小さいですが、「1つの製品」しかないとは言えません（@StephenC）。日付選択やポップアップアラートから、検索およびフィルタリング可能なリストとテーブル、ピボットテーブルとドッキングまで、すべてを備えた他のコンポーネントスイートを見つけることはできません。

彼らのサポートはシュールです。（@Carlosによると）唯一の媒体がフォーラムであることは事実ですが、彼らの回答の所要時間と質は本当に素晴らしいです（私はそこで3番目のトップポスターなので、私は知っています）。私の投稿の多くは、新機能とAPIの変更（例：プライベート->保護）リクエストであり、1〜2回のリリース（最大で数週間から1か月）でそれらの大部分を満たします。

完全なソースコードと難読化されていないデバッグjarのソースコードライセンスを購入できます。ピボットやドッキングなどのより複雑な製品を使用する予定がある場合は、そうすることを強くお勧めします（彼らから販売手数料を得ることができればと思います）。

ソースコードを入手したら、必要に応じて多くのカスタマイズを行うことができます。コードは非常にオープンで、拡張機能のために適切に構造化されているためです。文書化されていないクラス/メソッドを拡張するのは危険な場合がありますが、コードは非常に安定しています。

そして、私は彼らのコード品質が一流であると言わなければなりません。きしむようなクリーンではありませんが（Swing自体と同じくらいの大きさです）、頭をかいてWTFを不思議に思うことを余儀なくされたことはありません。

製品グループごとに非常に堅実な開発者ガイド（ページを下にスクロール）があります。javadocは優れています。完全なデモ自体は、コンポーネントと機能を探索するための優れた方法です。FlexDockよりもJIDEドッキングを選択した主な理由はドキュメントでした（後で、JIDEドッキングにもさらに多くの機能があることがわかりました）。

---

今難しい部分。

@Carlosが述べたように、リリースごとにリグレッションが発生します。完全に包括的で完全に自動化された回帰テストがあるようには見えませんが、特にピボットやドッキングなどの製品の複雑さとインタラクティブな性質を考えると、それはおそらく不可能に近いでしょう。彼らは物事を非常に速く修正しますが、他の回帰を見つけるためだけに、待ってから新しいバージョンにアップグレードしなければならないのは常に苦痛です。そうは言っても、私の会社のGUIアプリは、大きな問題なくいくつかのバージョンを出荷しています。

私は主に、日付選択ツール、バルーンチップ、ステータスバー、複数ページのダイアログなど、ある程度スタンドアロンのコンポーネントの多くと、最も複雑な2つの製品であるピボットテーブルとドッキングを使用しました。（申し訳ありませんが、JDAFはありません。）

それらは正当な理由で複雑です。OLAPは独自の業界であり、ドッキングはすべての最新IDEの基盤です。そのため、このセクションを「悪い部分」とは呼びませんでした。ピボットとドッキングは、品質のためではなく、複雑さのために使用が困難です。

たとえば、JIDEドッキングマネージャには70を超えるプリミティブBeanプロパティがあります（2.9.5以降）。相互に依存しているものもあり、特定のニーズに合わせて設定する方法を理解するには時間がかかります。

---

全体として、予約なしでJIDEをお勧めします。その妥当性のためにそれを使用できない場合、それは非常に残念です。その場合、そのデモを見ることさえしません。さもなければ、他のすべてが欠けていることに気付くでしょう。

Answer 2

私はJIDEを2.5年間使用しています。私に関する限り、これは（多くはないので）そこにある最高のSwingコンポーネントライブラリです。ここからコンポーネントを取得し、そこから別のコンポーネントを取得する場合は、一部の機能を他の代替機能に置き換えることができますが、一部は一意のようです。そしてもちろん、個別のコンポーネントやフレームワークではなく、1つの完全なソリューションを採用する方が簡単です。指摘しておきたいのですが、私は主にライブラリとドッキングフレームワークから別々のコンポーネントを使用しましたが、JDAFは使用していないため、コメントできません。
すべてのリリースで新しいバグが発生したため、ある時点で感じられましたが、ほとんどの部分で品質は良好でした。しかし、すべてのSwingリリースもそうなので、実際にそれらを非難することはできません。応答時間とカスタマーサービスは一般的に良好であるため、問題を抱えているのはあなただけではありません。彼らはまた、顧客のニーズに合わせて製品を適応させようとしているようです。
ただし、一部の部分では、それらの操作は少し素人っぽいようです。たとえば、前回チェックしたとき、彼らのフォーラムはまだバグデータベースとして使用されていました。彼らはまた、多数の新製品をリリースしており、そのうちのいくつかは永久にベータ段階で立ち往生しているようです。
導入料金については、総コストを把握し、製品を評価してから、他の代替手段のリスクとコストと比較してJIDEを採用することのリスクとコストを検討することをお勧めします。オープンソースもリスクフリーではありません。死んだ商用製品にとらわれることは、死んだオープンソース製品にとらわれるよりも悪いかもしれませんが、私も楽しみません。

Answer 3

私はこの製品に注意するでしょう：

• 顧客に配布したり、社内で大量に展開したりする場合は、「交渉可能な」展開料金が請求されるようです。

• JIDESoftwareは小さな1つの製品会社のようです。このような企業では、廃業したり買収されたりして、顧客が死んだ製品を手に入れるという重大なリスクがあります。

• JIDEを使用すると、アプリケーションをオープンソースにするのに支障をきたします...そのステップが将来の計画に含まれている場合。