次のブログの記事：http://blog.fogus.me/2011/07/21/compiling-clojure-to-javascript-pt1/ Googleクローズコンパイラによって行われた、JavaScriptのプログラミング言語に単純化された非常に信憑性の高い構文変換があります。Googleクローズのjavascript、Java用の最適化に相当するものはありますか？
私の質問ですが、Javaにこれらの種類の構文変換を提供するものがありますか？
一般に、Javaコンパイラは、JVMコードを生成するために一般的に有用な最適化を行うことができます。 JVMのJITコンパイラは、ネイティブマシンコードを生成するので、より多くの最適化を行います。これらは両方とも自動的で目に見えないので気づかずに明示的に行う必要はありません。
JavaコンパイラとJITコンパイラが実行することができないプログラムのコンテキストでは常に変換が行われることがあります。これらのためには、ソースコードを読み込んで、ある種のツール内部構造（通常はAST）に解析し、この内部構造で定義する「信じられない構文変換」を適用できる、ある種のソースからソースへの変換が理想的ですあなたの言語でソースコードを再生成します。
私たちのDMS Software Reengineering Toolkit（商用）はそのようなエンジンです。それは多くの言語を処理します。 DMSには完全なシンボルテーブルを構築し、より複雑な変換を可能にするために必要な制御とデータフローの分析を提供するJava 1.6 front endがあります。
フリー（大学リサーチ）の代替案は、いずれもJavaパーザをいくつか（私には知られていません）成熟していますが、シンボル表やその他のフロー分析を提供していません。またはあなた自身の悪い近似。 ANTLRという提案もありますが、これにはJavaフロントエンドがあり、おそらくASTを構築し、シンボルテーブルを作成しない可能性が高く、典型的な変換システムが行う残りの部分は提供しません（ソースからソースへの変換、ソーステキストの再生成など）
Javaコンパイラに満足すれば、これは必要ありません。十分でない場合は、このようなものが必要です。 [あなたが質問したという事実は、あなたがJavaコンパイラがやってくれないことをやりたいことが何であるかを示唆していることを示唆しています。具体的にはどうすればいいのですか？]
Javaとは異なり、JavaScriptは一般的にソース形式で配布されるため、Closureコンパイラは動作します。したがって、変数の名前を変更したり空白を取り除いたりすることは、Javaには適用されません。Javaアプリケーションは通常、バイトコード（しばしばJARファイルにパッケージ化されている）として配布されるからです。
その他の最適化については、JavaコンパイラとHotspot JVMには、アプリケーションの最適化とパフォーマンスの向上に非常に優れた手法が組み込まれています。
私の質問は、Javaにこれらの種類の構文変換を提供するものがありますか？
IMO、実際にはありません。
GoogleクローズコンパイラはJavascriptを入力として受け取り、（比較的意味のある）Javascript ASTの高水準変換を実行します。
Javaバイトコードコンパイラは実行できますが、Java ASTレベルで最適化する方法はあまりありません。代わりに、ほとんどの最適化をJITコンパイラに任せます。これは、（比較的意味のない）クラスファイルからの起動を最適化します。バイトコードである。
これは、JITコンパイラがGoogleクローズコンパイラが実行できる最適化の種類を実行することを困難にします。
Google Chrome for Javaと同等の理由がないのはなぜですか？考えられる理由は2つあります。
誰もそれを行っていないためです。 （私は具体的な例を思い出すことはできません...）
通常の手書きJava入力では、最適化の機会はそこにないため、
技術的な理由（下記参照）。
ほとんど第2の理由です。 Javascriptと典型的なJavascriptプログラムの動的な性質は、AST変換による最適化の機会が増え、ASTレベルのオプティマイザが通常のコードでより大きなスピードアップを達成できることを意味します。
今、それはウェルJavaソースコードは、ClojureのコンパイラASTレベルの最適化のためのだろう存在するより多くの機会を生成であってもよいです。そして、以前のASTレベルのJava最適化の試み（それらが存在すると仮定して）を再検討することは良い考えです。
私は上記で言及した「技術的な理由は、」次のとおりです。
Javaで一定の反射やイントロスペクション施設の存在は、実際に、最適化への障害となっています。たとえば、Javaコンパイラがテールコールの最適化を行うことができないと述べた理由は、コールスタックを見ることができないJavaコードを破るということです。その一例がセキュリティマネージャです。
Javaバイトコードコンパイラは、主に個々のコンパイル単位のレベルで動作します。つまり個々のクラス/インタフェース/などです.Googleクロージャコンパイラによって実行される高度な最適化の種類には、入力ファイルに多数のクラスが含まれています。
ダイナミックプログラムは静的プログラムよりも理由を考えるのが難しいです。 JavaよりもJavaScriptを最適化するのは難しいはずです（例えば、 "eval"と考える）。ツールがJavaのソースコードを読むことができない、または多くのJavaコンパイルユニットを読み込むことができない理由はありません。そして、これらのツールは存在します。私の答えを見てください（私たちのツールは、実際に膨大な数のJavaファイルを読み込んでセットに変換します）。 –
@Ira Baxter - 汎用リエンジニアリングツールキットは、Javaソースコードオプティマイザではありません。技術が関連しているとすれば、前者を使って後者を構築することができます。しかし誰かがそれをしなければならない。実際に作業をしていて、ベンチマークでは、Javaの一般的な入力の広い範囲で良い結果が得られることが示されています...興味深いでしょう。 –
クロージャコンパイラの目標の1つは、より効率的なウェブ配信を可能にするためにJavaScriptプログラムを「より小さく」することです。 DMSベースのツールは、ソフトウェアの保守上の理由からサイズの縮小を実現し、大規模なJavaスイート内のすべてのデッドエンティティを検出して削除し、より小さなJavaプログラムを作成します。この時点では、より一般的な目的のオプティマイザは行っていません。 –
これは私が話していたものです。 Iraは前に私の質問に答えました:)これを達成するためにオープンソースが同等ですか？ – hawkeye
@hawkeye：答えは無料のバージョンを追加するように改訂されました。 –