3

次のブログエントリを参照してください。http：//blog.fogus.me/2011/07/21/compiling-clojure-to-javascript-pt1/かなり信じられないほどの構文変換、javascriptプログラミング言語の簡略化、 GoogleClosureコンパイラ。

私の質問は-Javaにこの種の構文変換を提供するものはありますか？

4

3 に答える 3

5

JavaScriptは通常、Javaとは異なり、ソース形式で配布されるため、Closureコンパイラはそのように機能します。したがって、Javaアプリケーションは通常バイトコード（多くの場合JARファイルにパッケージ化されている）として配布されるため、変数の名前変更や空白の削除などの操作はJavaには適用されません。

残りの最適化に関しては、JavaコンパイラとHotspot JVM自体に、アプリケーションの最適化とパフォーマンスの向上に非常に優れた多くの手法が組み込まれています。それらの多くは、それらが存在することを知らなくても発生します。

于 2011-07-31T02:39:00.020 に答える
3

原則として、Javaコンパイラは、JVMコードを生成するために一般的に役立つ最適化を実行できます。次に、JVMのJITコンパイラは、ネイティブマシンコードを生成するため、さらに最適化を行います。これらは両方とも自動で表示されないため、気付くことはありませんが、明示的に行う必要はありません。

プログラムのコンテキストで実行される可能性のある変換は常にありますが、JavaコンパイラとJITコンパイラはそれを知ることができません。これらの場合、理想的には、ソースコードを読み取り、それをある種のツール内部構造（通常はAST）に解析し、これに定義する「信じられないほどの構文変換」を適用できる、ある種のソースからソースへのプログラム変換システムが必要です。内部構造を作成してから、ご使用の言語でソースコードを再生成します。

私たちのDMSソフトウェアリエンジニアリングツールキット（商用）はそのようなエンジンです。それは多くの言語を扱います。DMSには、完全なシンボルテーブルを構築し、より複雑な変換を可能にするために必要な制御およびデータフロー分析を提供する Java1.6フロントエンドがあります。

無料の（大学の研究）代替手段はStrategoとTXLであり、どちらもある程度の成熟度のJavaパーサーを備えていますが、シンボルテーブルやフロー分析を提供しないため、これらまたは不適切な近似を作成する必要があります。あなた自身。Javaフロントエンドも備えているANTLRは、おそらくASTを構築し、シンボルテーブルを構築しない可能性が高く、一般的な変換システムが行う残りの機構（ソースからソースへの変換）を提供しないことを示唆する人がいます。 、ソーステキストの再生など）

Javaコンパイラの機能に満足している場合は、これは必要ありません。それが十分に機能しない場合は、このようなものが必要です。[あなたが質問をしたという事実は、Javaコンパイラが実行しないことを実行したいという考えを持っていることを示唆しています。気になりますか？]

于 2011-07-31T02:49:59.240 に答える
0

私の質問は-Javaにこの種の構文変換を提供するものはありますか？

IMO、そうではありません。

  • Google Closureコンパイラは、Javascriptを入力として受け取り、（比較的意味的に豊富な）JavascriptASTの高レベルの変換を実行します。

  • Javaバイトコードコンパイラは実行できますが、JavaASTレベルでの最適化の方法では明らかに多くのことを実行しません。代わりに、最適化のほとんどをJITコンパイラに任せます...（比較的意味的に貧弱な）クラスファイルから開始して最適化します。つまり、バイトコード。

これにより、JITコンパイラがGoogleClosureコンパイラで実行できるような最適化を実行することが難しくなります。

では、なぜGoogle ClosureforJavaに相当するものがないのでしょうか。考えられる理由は2つあります。

  • 誰もやったことがないからです。（具体的な例は思い出せません...）

  • 最適化の機会がないため、通常の手書きのJava入力の場合。

  • 技術的な理由（以下を参照）。

IMOそれは主に2番目の理由です。Javascriptと一般的なJavascriptプログラムの動的な性質は、AST変換による最適化の機会が多く、ASTレベルのオプティマイザーが通常のコードの大幅な高速化を実現することを意味します。

さて、 Clojureコンパイラーを生成したJavaソースコードは、ASTレベルの最適化の機会を増やす可能性があります。また、JavaのASTレベルの最適化に関する以前の試みを再検討することをお勧めします（それらが存在すると仮定します）。

私が上でほのめかした「技術的な理由」には、次のものが含まれます。

  • Javaに特定のリフレクションおよびイントロスペクション機能が存在することは、実際には最適化の障害になります。たとえば、Javaコンパイラが末尾呼び出しの最適化を実行できないと述べられている理由は、呼び出しスタックを確認できないことに依存しているJavaコードを壊してしまうためです。そしてその一例がセキュリティマネージャです。

  • Javaバイトコードコンパイラは、主に個々のコンパイルユニットのレベルで動作します。つまり、個々のクラス/インターフェースなどです。GoogleClosureコンパイラによって実行される一種の高レベルの最適化には、多くのクラスを含む入力ファイルが含まれます。

于 2011-07-31T04:20:03.500 に答える