是否有相當於Google Closure對JavaScript的Java優化？

Question

我們在以下博客條目中看到：http://blog.fogus.me/2011/07/21/compiling-clojure-to-javascript-pt1/一些非常令人難以置信的語法轉換，簡化了JavaScript編程語言，由Google Closure編譯器完成。

我的問題是 - 是否有東西爲Java提供了這些類型的語法轉換？

Answer 1

作爲一般規則，Java編譯器可以/執行一些通常有用的優化來生成JVM代碼。 JVM中的JIT編譯器會進行更多的優化，因爲它會生成本地機器代碼。既然這些都是自動的並且不可見，你不會注意到，但你不需要明確地做。

在程序的上下文中，Java編譯器和JIT編譯器無法完成的轉​​換總是存在。對於這些，您最好想要某種源代碼到源代碼的系統，它可以讀取源代碼，將其解析爲某種工具內部結構（通常爲AST），應用您在此內部定義的「令人難以置信的語法轉換」結構，然後用您的語言重新生成源代碼。

我們的DMS Software Reengineering Toolkit（商業）就是這樣的引擎;它處理許多語言。 DMS有一個Java 1.6 front end，它構建完整的符號表並提供控制和數據流分析，這是進行更復雜轉換所必需的。

免費（大學研究）的替代品是Stratego和TXL，它們都有一些Java解析器（我不知道）成熟度，但絕對不提供符號表或任何類型的流分析，這意味着您必須構建這些或者你自己的近似值很差。有些人可能會建議ANTLR，它也有一個Java前端，可能會構建AST，很可能不會構建符號表，並且不會提供典型轉換系統所執行的其餘機制（源到源轉換，源文本的再生等）

如果您對Java編譯器的功能感到滿意，則不需要這些。如果它做得不夠，那麼你想要這樣的東西。 [你問這個問題的事實表明你對Java編譯器沒有做的事情有一些想法。注意詳細嗎？]

Answer 2

Closure編譯器的工作方式是這樣的，因爲與Java不同，JavaScript通常以源代碼形式分發。因此，重命名變量和消除空白等操作不適用於Java，因爲Java應用程序通常分佈爲字節碼（通常打包在JAR文件中）。

至於其餘的優化，Java編譯器和Hotspot JVM本身包含許多技術，這些技術非常適合優化應用程序並提高性能：其中許多技術只是在您不知道它們在那裏的情況下發生。

Answer 3

我的問題是 - 是否有某種東西爲Java提供了這些類型的語法轉換？

IMO，不是真的。

• Google Closure編譯器以Javascript作爲輸入並執行（相對語義豐富的）Javascript AST的高級轉換。

• Java字節碼編譯器可以這樣做，但在Java AST級別上優化方式顯然沒有多大作用。相反，他們將大部分優化都留給了JIT編譯器......它從相對語義較差的類文件開始優化;即字節碼。

這使得JIT編譯器難以執行Google Closure編譯器可以執行的各種優化。

那麼爲什麼沒有相當於Google Closure for Java的版本呢？有兩種可能的原因：

• 因爲沒有人做到了。 （我不記得任何具體的例子...）

• 因爲優化的機會不存在，對於正常的手寫Java輸入。

• 技術原因（見下文）。

IMO它主要是第二個原因。 Javascript和典型Javascript程序的動態特性意味着AST轉換有更多機會進行優化，並且AST級優化器將爲正常代碼實現更顯着的加速。現在

，它可能是的Java源代碼生成的Clojure的編譯器會爲AST級優化現在更多的機會。對於Java的AST級優化（假設它們已經存在），重溫之前的嘗試可能是一個好主意。

的「技術原因」我上面提到的包括以下內容：

• 在Java的某些反射和內省機制的存在實際上是阻礙了優化。例如，Java編譯器不能執行尾部調用優化的陳述原因是它打破了Java代碼，它不依賴於查看調用堆棧。一個例子是安全經理。

• Java字節碼編譯器主要在各個編譯單元的層次上運行;即單獨的類/接口/等。Google Closure編譯器執行的高級優化包括輸入文件包含許多類。