多くの人がJavaアプレットを置いているのを聞いて読んだことがあります。デスクトップ用に作成されたJavaアプリケーションがあります。しかし、数行のコードで、アプリケーションをアプレットとしてWebにデプロイできますか?私は彼らの何がそんなに悪いのか見当がつかない。アプリケーションをアプレットに変換するだけが悪いデプロイメントのアイデアである理由を誰かに教えてもらえますか?
3 に答える
デスクトップ用に作成されたJavaアプリケーションがあります。しかし、数行のコードで、アプリケーションをアプレットとしてWebにデプロイできますか?
数行のJNLPで、Java Web Startを使用してWebサイトから直接(J)Frameベースのプロジェクトを起動できます。
..アプリケーションをアプレットに変換するだけが悪いデプロイメントのアイデアである理由を誰かに教えてもらえますか?
「ブラウザ」。ご存知かもしれませんが、アプレットはブラウザによってレンダリングされるWebページのゲストです。ブラウザ/JRE/アプレットの相互作用のバグは、アプレット開発者の悩みの種です。隔週で新しいものがあります。ブラウザを避ければ、ほとんどの問題は一気に解決されます。
私は自分のサイトにアプレットを展開していますが、通常、Webページがアプレットに何かをもたらすことができる場合にのみアプレットを作成します。たとえば、JavaScriptを使用して構成されたプロパティアプレットがあります。
しかし、私の一般的なアドバイスは、可能な限りアプレットを避けることです。
個人的には、アプレットについて本質的に悪いことは何も見ていません。
アプレットには制限されたセキュリティ権限があるため、問題のシステムへのアクセスが少なくなります。ただし、Webを介して展開する場合、これが大きな問題になるとは思われません。
Javaアプレットには本質的に何も問題はありません。アプリは、JWSデスクトップアプリケーションとアプレットの両方としてデプロイされています。
ただし、アプレットにはいくつかの欠点があります。
まず、アプレットのあるページは、Java VMがまだ実行されていない場合、強制的に起動します。これにより、多くのシステムのユーザーに顕著な遅延が発生する可能性があります。(これは、アプレットのネガティブな原因の一部である可能性があります。これらは、はるかに少ないオーバーヘッドでDHTMLで簡単に処理できるナビゲーションバーなどのWebページで(過剰に)使用されていました。)
第二に、ブラウザのアプレットは、より制約のある実行環境になる傾向があります。JWSを使用していない限り、ファイルシステム、印刷、およびその他の多くのリソースにアクセスすることはできません。アプレットの元となったサーバーに戻る以外に接続を開くことはできません。通常、アプレットウィンドウのサイズを簡単に変更することはできません。おそらく他の問題もあります。
他の人がもっと欠点を指摘すると確信しています。:)