我们在以下博客条目中看到：http://blog.fogus.me/2011/07/21/compiling-clojure-to-javascript-pt1/ 一些非常令人难以置信的语法转换，对 javascript 编程语言的简化，由 Google Closure 编译器完成。
我的问题是 - 有没有什么东西可以为 Java 提供这些类型的句法转换？
【问题讨论】：
标签： java optimization refactoring compiler-optimization google-closure-compiler
Closure 编译器以它的方式工作，因为 JavaScript 与 Java 不同，通常以源代码形式分发。因此，重命名变量和消除空格等操作不适用于 Java，因为 Java 应用程序通常以字节码的形式分发（通常打包在 JAR 文件中）。
至于其余的优化，Java 编译器和 Hotspot JVM 本身结合了许多非常擅长优化应用程序和提高性能的技术：其中许多只是在您不知道它们的存在的情况下发生。
【讨论】：
作为一般规则，Java 编译器可以/执行一些通常有用的优化来生成 JVM 代码。然后，JVM 中的 JIT 编译器会在生成本机机器代码时进行更多优化。由于这两种方法对您来说都是自动且不可见的，因此您不会注意到，但您不需要明确地执行它们。
在您的程序上下文中，总有一些 Java 编译器和 JIT 编译器无法知道的转换。对于这些，您理想地想要某种源到源program transformation 系统，它可以读取源代码，将其解析为某种工具内部结构（通常是 AST），应用您定义的“令人难以置信的语法转换”这个内部结构，然后用你的语言重新生成源代码。
我们的DMS Software Reengineering Toolkit（商业）就是这样一个引擎；它处理多种语言。 DMS 有一个Java 1.6 front end，它构建完整的符号表并提供控制和数据流分析，这是实现更复杂转换所必需的。
免费（大学研究）替代品是Stratego 和TXL，它们都有一些（我不知道）成熟的 Java 解析器，但绝对不提供符号表或任何类型的流分析，这意味着你有自己构建这些或不好的近似值。有些人可能会建议ANTLR，它也有一个 Java 前端，可能构建 AST，很可能不构建符号表，并且不提供典型转换系统所做的其余机制（源到 -源转换，源文本的再生等）
如果您对 Java 编译器的功能感到满意，那么您不需要任何这些。如果它做得不够，那么你想要这样的东西。 [您提出这个问题的事实表明您对 Java 编译器不做的事情有所了解。需要详细说明吗？]
【讨论】：
我的问题是 - 有没有什么东西可以为 Java 提供这些类型的句法转换？
国际海事组织，并非如此。
Google Closure 编译器将 Javascript 作为输入并执行（相对语义丰富的）Javascript AST 的高级转换。
Java 字节码编译器可以做到，但显然在 Java AST 级别的优化方面做得不多。相反，他们将大部分优化留给了 JIT 编译器……它从（相对语义较差的）类文件开始进行优化；即字节码。
这使得 JIT 编译器更难进行 Google Closure 编译器可以进行的优化。
那么为什么没有与 Google Closure for Java 等效的产品呢？有两个可能的原因：
因为没有人做过。 （我想不起任何具体的例子......）
因为正常的手写 Java 输入没有优化机会。
技术原因（见下文）。
IMO 这主要是第二个原因。 Javascript 和典型 Javascript 程序的动态特性意味着有更多通过 AST 转换进行优化的机会，并且 AST 级优化器将为普通代码实现更显着的加速。
现在，很可能生成 Clojure 编译器的 Java 源代码将为 AST 级优化提供更多机会。重新审视以前针对 Java 进行 AST 级优化的尝试可能是一个好主意（假设它们存在）。
我上面提到的“技术原因”包括以下几点：
Java 中某些反射和自省工具的存在实际上是优化的障碍。例如，Java 编译器不能进行尾调用优化的原因是它破坏了无法查看调用堆栈的 Java 代码。安全管理器就是一个例子。
Java 字节码编译器主要在单个编译单元级别运行；即单个类/接口/等。Google Closure 编译器执行的高级优化类型涉及包含许多类的输入文件。
【讨论】：