grails - 多くの人が JVM を新しいアプリケーションにドラッグすることに固執するのはなぜでしょうか?

Question

たとえば、Rails アプリを死ぬほど怖がっているが、新しい Grails アプリを作成するというアイデアが大好きな開発者やアーキテクトに出くわしています。

私が見た限りでは、JVM を使用して直接の Ruby や Python ではなく、Groovy、JRuby、Jython などの言語をサポートすると、多くのリソースオーバーヘッドが発生します。

Ruby と Python はどちらもほぼすべての OS で解釈できるため、「一度書けばどこでも実行できる」という利点は見当たりません。

score 29 · Accepted Answer

Java は、たとえば Ruby や Python (さらに言えば Perl) よりも、「ドロップイン」して使用できる多くの既存のクラスライブラリを備えた、はるかに成熟したプラットフォームです。そのため、すべてを自分で作成するのではなく、既存のコードを使用するのが好きな人にとって、Java は大きなメリットです。

たとえば、最近、Python や Ruby の JAXB のようなものを探しています。最終的に、広く使用されている成熟した XML バインディングライブラリが見つからなかったという理由だけで、JRuby を使用することになりました。

score 14 · Accepted Answer

JVM 用のコードを (任意の言語で) 作成することの大きな利点は、必要に応じて、膨大な数の成熟した Java ライブラリを通常非常に簡単に利用できることです。

また、リソースのオーバーヘッドが非常に大きい「巨大な」JVM というアイデアをどこから得たのかもわかりません。JIT は非常に高速なコードを生成する傾向があり、コア JVM は今日の基準からすれば決して巨大ではありません。実行時に大量のメモリフットプリントが発生する傾向がありますが、これは、最新のマシンには大量の RAM があり、GC は使用する RAM が大量にある場合に最適に機能するためです。必要に応じて、GC を完全に微調整して、より保守的にすることができます。

他の誰かが言ったように、「Groovy の最も優れている点は、 Javaを使用する必要がないことです。Groovy の 2 番目に優れている点は、 Java を使用できることです」。

score 9 · Accepted Answer

質問に組み込まれているように見える仮定は、新しいプロジェクトはグリーンフィールドプロジェクトであるということです。多くの組織は過去10年以上にわたってJavaに巨額の投資を行っており、既存の（内部）コードエコシステム内で機能する新しいプロジェクトが必要です。指摘したように、公開されているすべてのJavaライブラリ（フリー/ OSSまたは商用）には大きなボーナスがありますが、既存のコードを操作する必要性、さらには既存のシステム内のコンポーネントとしても、少なくとも同じくらい重要です（それ以上ではないにしても）そう）大規模な組織に。

プラットフォームの成熟度と機能、つまりJVMとそれに付随するすべてのもの（Javaエコシステム全体）にも多くの問題があります。私の頭のてっぺんからいくつかの例：

リモートデバッガーを実行中のJVMにプラグインして、PythonやRubyなどでは単純に不可能な実行中のアプリケーションに関するあらゆる種類の情報を取得できます。さらに一歩進んで、オブジェクトができるようにコードを記述する標準的な方法であるJMXがあります。ライブアプリケーションで監視され、さらに調整されます。JConsoleを見て、少しだけよだれを垂らしていないかどうかを確認してください（インターフェイスの醜さにもかかわらず）。
この方向にさらに進んで、OSGiがあります。これは、ライブアプリケーションで展開、開始、停止、さらにはアップグレードできる高度にモジュール化されたコードを作成するための標準です。OSGiを使用すると、大きなアプリケーションを多数の小さな「バンドル」に分割し、それらを個別に保守（デプロイ、開始/停止、アップグレード）することができます。これは、大規模なアプリケーション、または常に実行し続ける必要のあるアプリケーションでは非常に大きな問題です。
このプラットフォームは、非同期で信頼性の高いメッセージングを非常によくサポートしています。ベースラインとしてJMSを取得し、非常に少ないコードで複雑なことを実行するために、JMS上に構築された多くの優れた強力なライブラリを取得します（Apache Camel、ServiceMix、Muleなどを参照）。これは、大規模なアプリケーションや、大規模なコードユニバース内で実行する必要があるアプリケーションで非常に役立つもう1つの機能です。
JVMには実際の（OSレベルの）スレッドがありますが、Pythonetal。この点で非常に制限されています（悪名高いように）。（そうは言っても、共有状態の並行性（スレッド化）は間違ったアプローチです。Erlang、Alice、Mozart / Ozなどを参照してください。）
JRockit 、IBMのJVMなど、標準のSun実装以外にも多数のJVMの選択肢があります。これは他の言語の開発領域です。PythonにはJython、Iron Python、さらにはPyPyやStacklessがあります。RubyにはJRuby、Rubiniusなどがありますが、これらはさまざまなJVM製品に見られる成熟度に匹敵するものではありません。

そうは言っても、私はJavaという言語が本当に好きではなく、可能な限り避けています。最近では、JVMのすべての優れた代替言語を使用する必要はありません。Groovyは、そのアクセシビリティとプラットフォーム（さらには言語）との緊密な統合、そして私が時々「大人のためのレール」と呼ぶGrailsのおかげで私の投票を得ました。私は他のJVM言語、特にClojureとScalaの方が好きですが、これらは平均的なプログラマーにはアクセスできません。ただし、Scalaは最近多く登場していますが、特にTwitterでの注目度の高い使用のおかげで、より大規模な環境でScalaを作成するための面白くて本当に優れた言語が期待されています。しかし、それは別のトピックです。

score 7 · Accepted Answer

なぜあなたと一緒に巨大なJVMを持ってくるのですか？

JVM は肥大化せず、遅くもありません。それどころか、無駄がなく、高速で、深く最適化された VM です。残念ながら、静的 OOP 言語用に最適化されています。

それでも、JVM を対象とする優れたコンパイラは、優れたパフォーマンスのプログラムを作成します。JRuby については知りません。しかし、Jython の目標は、通常の C Python よりも全体的に高速であることであり、それに近づいています (いくつかの重要なユースケースでは既に高速になっています)。

優れた JIT (JVM 用のものなど) は、静的 C コンパイラでは利用できないいくつかの最適化を適用できることを忘れないでください。それらからより高速なコードを取得することは夢物語ではありません。もちろん、言語用に最適化された VM は、JVM のような「一般的ではない」VM よりも高速である必要があります。ただし、成熟度の問題があります。JVM では多くの作業が行われていますが、Ruby と Python の JIT はそれほど進んでいません。

残念ながら、より優れた汎用バイトコード VM はないようです。Microsoft の CLI には、JVM と同様の制限があります (ironPython は JPython よりもはるかに遅く、重いです)。最有力候補はLLVMのようです。LLVM を超える動的言語がない理由を知っている人はいますか? いくつかの Scheme コンパイラを見てきましたが、いくつか問題があるようです。

score 4 · Accepted Answer

Groovy はインタープリター言語ではなく、動的言語です。groovy コンパイラーは、他の Java クラスと同様に JVM 内で実行される JVM バイトコードを生成します。この意味で、groovy は Java と同じであり、JVM ではなく開発者にとってのみ意味のある構文を Java 言語に追加するだけです。

開発者の生産性、シンタックスの使いやすさ、および柔軟性により、Groovy は Java エコシステムにとって魅力的なものになっています。Java バイトコード (jython を参照) が得られるのであれば、Ruby や Python も同様に魅力的です。

Java 開発者は実際には Ruby を恐れていません。実際のところ、多くの人がすぐに groovy や jython を採用し、どちらも ruby や python に近いものになっています。彼らが気にしていないのは、そのような素晴らしいプラットフォーム (Java) を、パフォーマンスが低く、スケーラブルでなく、Ruby などのあまり使用されていない言語 (すべてのメリットがあるにもかかわらず) に任せることです。

score 3 · Accepted Answer

RoR の大きな欠点は、スケーラブルではなく、展開が難しいことです。Java プラットフォームを使用することで、既存のインフラストラクチャを活用できます。

grails war

Glassfish、Jboss などに簡単にデプロイできる war ファイルを生成します。

score 3 · Accepted Answer

Ruby と Python はどちらもほぼすべての OS で解釈できるため、「一度書けばどこでも実行できる」という利点は見当たりません。

主な理由は、Java ライブラリ、API、および製品の巨大な既存のエコシステムを利用したいためです。これらのエコシステムは、特にエンタープライズドメインで Ruby や Python で利用できるものを小さくします。

また、JRuby と Jython は多くのベンチマークで、通常の (C 実装の) 言語、特に Ruby (Ruby 1.9 でさえも) よりも高速であることを覚えておいてください。

同じ仮想マシンを対象とする複数の言語を使用すると、共通のインフラストラクチャ、コードの再利用、共有 API の活用、概念的に最適な言語を使用する機能、または特定の問題領域に使用する機能など、多くの利点があります。

複数の言語が CLR を対象とする .NET 空間でも同じことが起こります。Parrot ( vaporware ) VM プロジェクトも同じことを目指しており、それはLLVMプロジェクトの明確な目標でもあります。

score 2 · Accepted Answer

2

その理由はホットスポットです。

エンジニアリングの傑作です。

于 2009-04-21T22:38:23.110 に答える

score 1 · Accepted Answer

あまり言及されていない他の理由は、jvmに関連する既存のインフラストラクチャです-すでにJavaのものを実行しているサーバーがある場合は、さらに別のプラットフォーム（レールなど）を導入する代わりにそれを使用してみませんか？

score 1 · Accepted Answer

私はこれに遭遇し、それに困惑しました。これが私の理論です。

エンタープライズソフトウェアは、Java プログラマーでいっぱいです。あらゆる種類のプログラマーと同様に、多くの Java プログラマーは、自分の言語が最も速く、最も柔軟で、最も使いやすいと確信しています。他の言語にはあまり詳しくありませんが、それらを実践するのは野蛮人で野蛮人に違いないと確信しています。当然のことながら、賢明な人なら誰でも Java を使用するからです。

これらの人々は、広大で複雑な Java インフラストラクチャを構築しました。フレームワークの rube-goldberg マシンと、複雑な継承構造と非常に大きな XML ファイルでいっぱいの自動生成コードです。

そのため、誰かがやって来て、「C インタープリター言語を使用しましょう! 高速で、きちんとしたライブラリがあり、スクリプト作成とプロトタイピングがはるかに高速です!」と言うと、Java 担当者はまず、「これを構成するには make ファイルを実行する必要がありますか? QUEL HORREUR!」と言います。次に、古い OS と古いバージョンの Tomcat を実行しているサーバーにこれをデプロイしてホストしなければならないという現実が始まります。

「ほら、知ってるよ！このインタープリター言語のJava版があるんだよ！ラッシュアワーの橋の高速車線で故障するかもしれないし、時々発火するけど、Tomcatに走らせることはできるよ」 Java 以外のことを学ぶために手を汚す必要はなく、それを既存のインフラストラクチャに押し込むことができます! 勝つ!」

では、これはスクリプト言語の Java 実装を選択する「正しい」理由でしょうか? おそらくそうではありません。「正しい」の定義によります。しかし、それが、私のようなスノッブが信じたいよりも頻繁に選ばれる理由だと思います.

grails - 多くの人が JVM を新しいアプリケーションにドラッグすることに固執するのはなぜでしょうか?

10 に答える 10

Related

Reference