13

GCJ を使用してサーバー側アプリケーションを公開することは本当に実行可能ですか? ウェブアプリ？

私の上司は、私たちの (私の) Web アプリケーションをバイナリ実行可能ファイルにコンパイルすることは素晴らしいアイデアだと確信しています。（繰り返しになりますが、彼は理解できる点滅するライトが付いた素敵で小さくてシンプルなものが好きです。） 彼は本能的にこれに問題はないと考えていますが、私は問題と劣化の無限のシリーズしか見ません。プラットフォームの複雑さ、バイト コード、JVM、ライブラリ、オペレーティング システム間の違い、プロセッサ アーキテクチャなどの詳細について彼に話し始めると...まあ...彼の目は輝き、彼は微笑み、彼は、私が幼稚な抵抗をしていると考えていることを明らかにしました.

なぜ彼は単一の魔法の実行可能ファイルが必要なのですか? 彼は、いくつかの「利点」を見ています。

  • バイナリ実行可能ファイルの場合、リバース エンジニアリングを行ってライセンスを回避することは困難です。経営陣は、サーバー ソフトウェアで一般的にチートを行わない大企業に販売しているにもかかわらず、これが起こっているのではないかと常に恐れています。
  • この魔法の実行可能ファイルをダウンロードして実行すると、すべてが機能するというビジョンがあります。（それほど頻繁ではない顧客のインストールを行うために私を送る必要はもうありません。）

それで、私は必須の 20 分間のグーグル検索を実行し、今ここにいます。

私のアプリケーションの背景のビット:

それは何から作られています：

  • Java 6 (Sun の JVM)
  • アスペクトJ 1.6
  • トムキャット6
  • 休止状態 3
  • 春 2
  • さらに 20 個のサポート jar ファイル

機能

  • ストリーミング メディア CMS
  • パフォーマンス重視
  • Linux、Solaris、Windows に展開 (および Mac で開発)

お察しのとおり、私はこの「Java をネイティブ コードにコンパイルする」ことに非常に懐疑的です。Mono (Linux 上の VB) が 2000 年に戻った場所のように聞こえます。しかし、私は過度に悲観的ですか? それは実行可能ですか？これを試すために実際に時間 (数週間ではないにしても数日) を費やす必要がありますか?

他にも同様のスレッドが 1 つあります ( .exe ファイルを生成するための Java コンパイラ オプション) が、少し単純すぎて、リンクが古くなっていて、実際にはサーバー側の質問に対応していません。

親愛なる SOped の皆さん、あなたの情報に基づいた意見は非常に大切にされます。ティア！

4

8 に答える 8

6

GCJ についてはわかりませんが、私の会社では Excelsior JET を使用して成功しています。(まだ) webapp でそれを行っていませんが、Sun JRE ができることは何でも処理できるはずです。実際、JET は Sun 認定の Java 実装です。

于 2008-09-15T17:52:12.340 に答える
4

FWIW: 私は GCJ で幸運に恵まれたことは一度もありません。GCJ を使用する際に多くの問題が発生し、いくつかのあいまいな問題が発生し、私ではなく GCJ が診断するのに永遠に時間がかかりました (私は常に、物事を外部のせいにするのを非常に嫌がります)。ライブラリ）。私はこれが数年前に起こったことを公然と認めます.GCJの近くに二度と行きたくありません. もっと具体的に言うと、これは私が在学中のことで、ほとんど些細なプログラムに取り組んでいたため、「エンタープライズレベル」で GCJ に対して健全な恐怖を感じていました。

于 2008-09-15T17:47:03.460 に答える
3

Excelsior JET is the definitive answer

于 2010-09-18T05:20:12.547 に答える
2

実行可能ファイルが1つあると、いくつかの欠点があります。

  • 簡単にパッチを適用することはできません（つまり、1つのクラスファイルを置き換える）
  • Webアプリとは呼べないと思います。Tomcatでは動作しないと思います。
  • これは非標準であるため、メンテナンスコストが増加します。
  • これは非標準であるため、ツールのサポートが減少します。

彼が何か簡単なことをしたいのなら、おそらく戦争か耳が良いでしょう。これを行うことのメリットはわかりません。ユーザーがダブルクリックするだけで配布できるスタンドアロンアプリケーションである場合、これはメリットがあると思います。

于 2008-09-15T19:03:21.140 に答える
0

私はGCJについてほとんど知りませんが、悪魔の擁護者を少し演じます.

ネイティブ コードにコンパイルすると、アプリケーションのパフォーマンスが向上し、使用するメモリが少なくなる可能性があるため、動作させることができれば、競争という点でビジネスにメリットがあります。

アプリケーションをより適切にサポートできることは、ビジネスにとっても良いことです。

したがって、動作しないアプリケーションほど顧客を失うのが早いということを念頭に置いて、調査する価値はあるでしょう。

これを試すには適切なプロジェクト時間が必要であり、顧客が何をしようとしているのかを知っていて、喜んでそれを提供してくれる (見つけにくい) 必要があります。

于 2010-09-17T10:51:49.397 に答える
0

私は GCJ をごく短時間しか使用しておらず、すぐに Sun の JDK に移行しました。私が見た主な問題は、GCJ が Sun の JDK の最新バージョンよりも常に少し遅れているように見えることと、Sun の JDK との微妙な違いによって引き起こされる不可解なバグがあることでした。バージョン 1.5 (Sun の v1.5 と互換性があると思われる) では、ジェネリックを使用したコンパイルに問題があり、最終的にあきらめて Sun の JDK に移行しました。

パフォーマンスの違いはごくわずかであり (私の目的では YMMV)、インストールの問題の実際の解決策は、アプリのインストーラーを作成することです。バイナリのリバース エンジニアリングは、バイトコードのリバース エンジニアリングほど難しくありません。それほど重要な場合は、難読化ツールを使用してください。

全体として、GCJ の使用に伴う互換性の問題は、GCJ から得られる可能性のある利点 (せいぜい疑わしいと思います) よりもはるかに重要だと思います。アプリの一部を gcj でコンパイルしてみて、どうなるか見てみましょう。それがうまくいけば、上司に売り込むためのしっかりしたものを手に入れることができます。

于 2010-09-17T10:27:34.680 に答える
-1

おそらく、あなたの上司は、顧客のアプリケーション サーバーに war ファイルを簡単に配布して展開する方法についてのデモを必要としているだけでしょう。すべてのファイルは「バイナリ」であるため、コマンドラインで実行可能ファイルを意味すると考えるのは文字通りすぎるかもしれません。

于 2008-09-16T14:28:37.670 に答える
-1

あなたのような大規模なアプリケーションがマシン コードにコンパイルされるとは思いません。Java は Java 構文 (マシン コードにコンパイルされる可能性があります) であるだけでなく、アプリケーション/プロセス環境に似た仮想マシンでもあることに注意してください。代わりに、 uberjarなどを作成することをお勧めします。

于 2008-09-15T17:47:11.073 に答える