Windowsデスクトップアプリケーションのランタイム/言語を選択するときに考慮すべき要素は何ですか？

すべてのユーザーがWindowsを使用しています。LinuxまたはMacを使用するものもありますが、使用する場合は、Mono、Wine、Parallels、デュアルブートなどを使用できます。

私の開発チーム（自分も含む）は、JavaでのSwingアプリケーションの作成と、C＃でのWindowsフォームの作成の両方で幅広い経験を持っています。「広範囲」とは、両方のランタイムで3つ以上のアプリケーションを開発して出荷したことを意味します。アプリケーションはテクニカル分析アプリケーションであるため、データベースの相互作用は穏やかですが、カスタムUIとデータセットのサイズは重いです。

どちらをサポートするかが重荷になっているため、これからどちらのプラットフォームに焦点を当てるかについて本当に決定したいところです（Swingで半年間作業していると、面倒すぎます）再びWindowsフォームに慣れるために（そしてその逆））、私たちはチームの全員がすべてのアプリケーションで作業できるようにしたいと考えています。

• Windowsフォームは一般に、認識可能なWindowsアプリケーションを作成するために必要な作業が少なくなります。Javaのスキニングとカスタムコントロールの量は、長年にわたってそれを解決していません。同時に、Swingアプリケーションを使用できないお客様はいません。
• Javaは以前、ライブラリと自動ビルドツールの点ではるかに豊富なエコシステムを備えていましたが、急速に変化しています（Javaは低下しておらず、.NETが追いついているだけです）。
• マルチプラットフォームが好まれているまれなケースでは、Javaは.NETに勝るものはありません。Monoはすばらしいですが、それでもJavaよりも多くの作業が必要です。

.NETを選択すると、WPFに焦点を当て始めることができますが、F＃の使用も開始できます。Javaを選択すれば、RCPに焦点を当て始めることができますが、Scalaの使用も開始できます。

誰かが同様の決定をしなければならなかったのですか？もしそうなら、それは何でしたか、そしてあなたに最も影響を与えたものは何ですか？私が見逃している最大の懸念はありますか？

（注意：Programmers.SEには同様の質問が既にいくつかありますが、それらは非建設的であるか、別の角度からです。）

私たちはJava（Swing）に加え、JNIを介していくつかのネイティブパーツに行きました。今日のマルチプラットフォーム性に対する商業的需要はわずかなものかもしれませんが、状況は5年で異なる可能性があり、アプリ（科学的測定アプリ）のライフサイクルは10年以上になりそうです（現在も使用されているC ++の前身） 1991年付けのソースファイル）。あなたが書いたように、JavaはWindows以外の環境では.NETの手を打ち負かしており、Windowsから切り替える必要がある場合は、ネイティブパーツを再コンパイルして、GUIの外観を微調整し、それを確認するだけです。すべてが機能します。

Windowsのみであり、アプリが数年しか存続しないと確信している場合は、.NETの方が適している可能性があります。しかし、長期的な投資として、私はJavaをより信頼しています。Swingの外観は完璧ではなく、起動時間が長くなる可能性があります。マルチプラットフォームの抽象化レイヤーのため、すべてが少し最適ではありませんが、少なくとも「動作する」だけです。

考慮する必要があるのは、.NETの世界でJavaコードを使用できるようにするIKVMプロジェクトです。その後、Javaバックエンドの利点を得ることができますが、私の理解では、SwingまたはWinFormsのいずれかに薄いフロントレイヤーを配置できます。

http://www.ikvm.net/

面倒な.NETバージョンを使用する代わりに、.NETからJavaで記述されたオープンソース接続ライブラリを使用するためにこれを使用している人もいると聞きました。

あなたに役立つかもしれないMSDNのリソースがあります：http : //msdn.microsoft.com/en-us/gg715299.aspx。

ページの下部に移動すると、Javaと.NETを概念的に比較したホワイトペーパーがたくさん見つかります。もちろん、MSDNにあるため、.NETに偏っていますが、リソースは依然として非常に便利です。

私もこれについていくつか考えましたが、答えはプロジェクトのタイプとそれについて何を予測できるかによって異なります。

場合によっては、すべてのプラットフォームにサービスを提供するOne Codebaseを作成することは良いことです。全体的なコードが少なくても、ある程度のUIの一貫性が得られます。長所と短所は明らかだと思うので、スキップします。

2つのネイティブに記述されたコードベースを使用する方が良い場合があります。たとえば、WPFでアプリを書くことが.NETに対してエレガントで、たとえばCocoaがMac OSに対してエレガントである場合、結果として得られるコードは、JavaやMono（たとえば、 WPF）。その場合、少ないコードでより良い結果が得られる可能性があります。

最後の考慮事項は、おそらくあなたのアプリをHTML5アプリケーション、あるいはChrome拡張機能として実行することですが、それはあまりにも残されたフィールドかもしれません。

Silverlightを検討しましたか？これは、Windowsデスクトップアプリケーション（SL4 +以降）のビルドやMacでの正常な動作にも適しています。

フルタイムのJava開発者として、クロスプラットフォームの互換性はすばらしいものの、ネイティブの統合はどれも地獄だと言えるでしょう。

この点で、私は常に多くの問題を抱えており、時には失敗しました。あなたはそれを必要としないかもしれませんが、時々私はそれにつまずき、それは通常痛いです。

• COMとの統合は苦痛であり、COM +が不可能な場合があります（WindowsタブレットAPIで動作させるために数週間も無駄に費やしていました）。
• ハードウェアの相互作用が害を及ぼす可能性があります。APIは1つのプラットフォームでのみ利用できる場合があります（カメラ/スキャナーの統合など）。
• ローカルアプリケーションとの相互作用も害を及ぼす可能性があります。COMの痛みについて言及しましたか？まあ、もう1つの方法（実際に使用した方法）は、MapPointや独自のマッピングアプリなどのWindowsアプリケーションを起動してデータを供給するVBSスクリプトを生成して実行することでした。
• インストールとデスクトップ統合（ショートカット、アンインストーラー、スタートメニュー）も害を及ぼす可能性があります。Web Startは非常に信頼できません。代案はあなたにかなりの費用がかかるか、またはいくつかの機能（アップデート配布のような）が欠けています。

誤解しないでください。私はJava開発者であり、非難するつもりはありません。私が言っているのは、もしあなたが上記のいずれかが必要だと疑うなら、それは害を及ぼす可能性があり、あなたは.netを使う方がよいかもしれないということです。少なくともそれはあなたが考慮に入れるべき引数です。