我们在以下博客文章中看到：http://blog.fogus.me/2011/07/21/compiling-clojure-to-javascript-pt1/一些非常令人难以置信的语法转换，简化了javascript编程语言，由Google Closure编译器完成。
我的问题是 - 有没有为Java提供这些语法转换的东西？
答案 0 :(得分：5)
Closure编译器以它的方式工作，因为JavaScript与Java不同，通常以源代码形式分发。因此，重命名变量和消除空格等操作不适用于Java，因为Java应用程序通常以字节码形式分发（通常打包在JAR文件中）。
至于优化的其余部分，Java编译器和Hotspot JVM本身包含了许多非常擅长优化应用程序和提高性能的技术：其中许多技术只是在您不知道它们存在的情况下发生。 / p>
答案 1 :(得分：3)
作为一般规则，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编译器不能做的事情有所了解。注意详细说明？]
答案 2 :(得分：0)
我的问题是 - 有没有为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编译器执行的高级优化涉及输入文件包含许多类。