Java Webブラウザが可能であることは知っていますが、実用的ですか?Loboプロジェクトを見て、感銘を受けたことを認めなければなりませんが、私が収集したことから、2009年に開発が停止したようです。 ChromeやFirefoxのランクに含まれるものですか、それとも本質的に速度が遅く、ユーザーを妨げますか?
Java Webブラウザが可能であることは知っていますが、実用的ですか?Loboプロジェクトを見て、感銘を受けたことを認めなければなりませんが、私が収集したことから、2009年に開発が停止したようです。 ChromeやFirefoxのランクに含まれるものですか、それとも本質的に速度が遅く、ユーザーを妨げますか?
回答:
プログラミング言語は、ほとんどの場合、障害になることはありません。JVMの必須メモリ管理は、パフォーマンスが重要な部分では不利になる場合があります(たとえば、メモリが飢えます。しかし、JavaのGCは、実際に自分でロールバックできるものよりもメモリリークの防止に優れている場合があります)。しかし、それ以外には、明らかなショーストッパーはありません。
しかしながら。
FirefoxまたはChromiumの規模のWebブラウザーは大規模な取り組みであり、両方のプロジェクトの背後には膨大な経験があります-Mozillaは数十年のブラウザー構築(およびいくつかの有名な失敗)に基づいて構築され、Chrome / ChromiumはGoogleとApple (WebKitの開発における主要な力)の背後にあり、KDEやその他の大規模な堅固なオープンソースプロジェクトから多くの知識と経験を吸収しました。どちらも、レンダリングエンジンだけでなく、あらゆる種類のさまざまな実績のあるライブラリを利用しています。ベクターグラフィックス、フォントレンダリング、解析、XML DOMツリー操作、ネットワーク、キャッシング、暗号化、リストは延々と続きます。これらすべての車輪を自分で作り直すのは望ましくありません。 。
要するに、業界強度のWebブラウザを構築することはかなり気難しく、それはだ、この分野での成功事例のほんの一握りがある理由。プログラミング言語はそれとはほとんど関係ありませんが、技術的にも社会的にもCとC ++が有利です。
理論的には、間違いなく実行できます。ただし、実際的な観点からは、もう少し疑問の余地があるようです。lobo
試されたのは初めてです。実際、Javaの優位性の初期のショーケースの1つは、世界を変え、「モザイク生成」ブラウザーを廃止するHotJavaブラウザーであると想定されていました。
もちろん、HotJavaが死んでいて、ブラウザ戦争の真の競争相手ではなかったことは事実です(実際、「HotJavaブラウザ」を検索した場合、トップヒットのいくつかはバグレポート用です。 Sun自身のWebアプリであっても、まったく正しく機能しなかった方法について)。
個人的には、それが可能か実用的かについて疑問に思うのは、(ほとんど)間違った方向に目を向けて考えることです。問題は、そのようなプロジェクトが非実用的であるためにJavaがそのような大きなペナルティを負うかどうかではありません。問題は、そのようなプロジェクトを正当化するのにJavaに十分な利点があるかどうかです。
単純な事実は、Webkit(例を使用するため)は大きくて複雑なコードであるということです。Javaが非常に素晴らしく、たとえばサイズと複雑さの半分で同じことができると仮定した場合でも、結果は依然としてかなり大きく複雑なコード(V8など)になります。
その作業量を複製する前に、ほとんどの人は、「当社の製品はかなり競争力があると思われます」よりも少しだけ保証が必要だと思います。
ブラウザーの一連のユーザー表示機能から開始し、それらの機能を備えたブラウザーを作成する最も効率的な方法を決定しようとすると、「Java」はおそらく「 Javascript」。歴史が違った形で働いていたなら、おそらく少なくとも理論的には答えの一部になれない理由はないでしょうが、現在の状況を考えるとそうではありません。
さらに、その変化の可能性はほとんどありません。Oracle(または場合によってはIBM)がJavaの競争力を維持することが有用であると判断した場合(ほとんどの場合はMicrosoft Microsoft。
それ以外では、想像できるあらゆる機能セット(「Pure Javaで記述された」それ自体の機能以外)は、ブラウザを完全にJavaで記述するよりも、他の方法でほぼ確実に迅速かつ容易に実現できます。
献身的で知識豊富なチームがJavaで高性能なWebブラウザを作成できると正直に信じています。本当の質問は、なぜですか?ブラウザを特定の言語で作成することは、実際には機能ではありません。Chromeは高速であるため、またはFirefoxは拡張可能であるため使用されますが、Javaで記述されているという理由だけでJBrowserは使用されません。本当の質問は、あなたはどの問題を解決しようとしているのですか?
JBrowserを作成する理由があると仮定した場合の次の質問は、「Javaを使用するとタスクが簡単になりますか、それとも難しくなりますか?」です。Googleは、Chromeを作成する際、非常に親Javaショップであるという事実にもかかわらず、主にC / C ++で作成しました。Javaの恩恵が時間通りに純益をもたらさないと彼らが信じた可能性が非常に高いようです。
Nashorn(Rhinoに代わるJVM上のJavascript)がJava 8の一部としてJVMに来ると、これは非常に実行可能です。ただし、他の人が指摘しているように、最新のWebブラウザーには非常に多くの機能があり、Javaアプリ内でブラウジング機能をホストする必要がある場合は、WebKitを組み込む方が簡単だと思われます:-)。
現在のトップアンサーは素晴らしいです。ただし、何かをJavaに完全に再コーディングする必要はありません。さまざまな程度の相互運用性を備えたネイティブソースをJavaバイトコードに変換するツールがあります。多くの場合、ある種のインタープリターを作成するか、MIPSなどのJVMのような表現を踏み台として使用します。主要なネイティブライブラリをJavaバイトコードに変換し、それらをピュアJavaブラウザソースと統合し、徐々にライブラリコードをピュアJavaソースとして実装することにより、Javaブラウザ開発を多くのステップに分割できます。
これにより、より安全なJVM内にすべてを含めることができます。ただし、効率性を確保するために苦労します。アジャイル/ OOP以前の大規模なレガシーアプリケーションを徐々にリファクタリングする先例があります。さらに、一部のコンポーネントにはすでに優れたJava実装があり、それらを使用して労力を削減することもできます。
ここでは少し偏っていると言わざるを得ませんが、ここに行きます。私はC / C ++の説教者が好きではありません、信じられないほど優れたエンジニアリングアプリケーションがあることは知っていますが、その単なるツールであり、多くの人が解決策のためにC / C ++に言及しているだけで、Aポイント( http://www.paulgraham.com/avg.html電球のパラドックスをご覧ください)。私は事実を見ようとします:JavaはC / C ++と同じくらい高速ですが、したがってより多くのメモリが必要です。または、C / C ++と同じくらい速いJavaコードを書くことができますが、そのプログラムはより多くのメモリを消費します。これに同意できるといいのですが。
生産性を見ると、特定の問題に対するJavaソリューション(エンタープライズJavaなど)をC ++ソリューションと比較して比較的簡単に作成できます。Webブラウザーはまったく異なるものです。2/3の市長の要件があります。
要約すると、はい、できます。ほとんどのプログラミング言語でブラウザーを作成して、今日のC ++蒸気船とほぼ同じ結果を得ることができます。しかし、そうするためには、かなりの労力が必要になります。どれだけ(何百万単位)分からないので、それを推測したくもないでしょう。おそらく、この最終結果を得ることができます:人々は高レベル言語で最適化することを好まないか、多すぎるためにC / C ++で最適化することを好む人々を得るのが安いかもしれません(最適化できる他の言語専門家と比較して同様のレベル)。
これは、ソフトウェアOpenGLとハードウェアアクセラレーションOpenGLを実行するWindows 9x時代のコンセプトに匹敵します。WebブラウザーのようなものにJavaを使用する場合の問題は、多くの余分なクロックサイクルを使用して、よりネイティブな言語でより少ない言語で可能なことを行う可能性があることです。それはOpenGLのコンセプトでもありました。タスクを完了することはできましたが、それを行うにはさらに多くの処理が必要でした。
だから、それは可能ですか?潜在的に。競争力がありますか?ありそうにない-高度に最適化されたプラットフォーム依存のコードには、速度の面で大きな利点があるでしょう。
ただし、これは単なる推測にすぎません。
Javaで書かれたJava Webブラウザーの実現可能性について、おそらく間違った質問がされました。
既存のもののほとんどが無料で豊富な機能を備えている場合、車輪を再発明して本格的なブラウザを書く必要はないと思います。
それは、私(私たち)が探しているべきものは、積み重なるすべてのがらくた(広告、ビデオ、gif)なしでウェブページを読むのに十分な「何か」であると言いました。
Googleは、すべての広告などの主要な犯罪者です。
それに対処するために、HTML 3.2実装でJava HTMLEditorKitを使用し、Webページをテキストとして読み取り、すべてのjavascriptコード、スタイルコード、リンク、メタデータ(自動での刺激の別のソース)を取り除くJavaブラウザーを作成しました再読み込み)、JavaScriptを介して設定されたいくつかの特殊文字と画像リンクの修正を試みます。ハイパーリンクとナビゲーションが機能します。LA Times、NY Times、Il Corriere.it、ElPais.es、LeMonde.frのようなものを読むために。BingやGoogleの検索も通過します。最終的にまたは尋ねられたとき、私は無料で利用できるようにします。大したことではありませんが、始まりです。
確かにそれを行うことができます。そしてそれも理にかなっています。不明な理由により、完全なw3c標準をサポートするブラウザはありません。css3サポートの部分では、ブラウザー企業も標準をサポートしていません。-moz- *および-webkit- *が標準の一部になることはありません。したがって、標準に完全に準拠したブラウザはそれらを無視する必要があります。w3cの最大の間違いの1つは、レンダリング仕様がまったくないことです。そのため、同じ標準に準拠したWebページは、ブラウザごとに異なって表示され、グラフィックデザインの悪夢になります。別のw3cの失敗は、速度の不足です。5年間の議論で、まだhtml5のドラフト標準だけですか?その後、組織は深刻なイノベーションをブロックしています。
レンダリング仕様とセキュリティを念頭に置いて、Webアプリケーションマークアップ言語の半年以内にw3cを無視し、その仕様を無視し、コミュニティ標準を作成する必要があると思います。sgmlがHTMLの基礎として使用された時点ではWebアプリケーションがなかったため、HTMLはWebアプリケーション用に設計されたことはないことを忘れないでください。