是否有相当于 Google Closure 对 javascript、Java 的优化？
我们在以下博客条目中看到： http:// blog.fogus.me/2011/07/21/compiling-clojure-to-javascript-pt1/ 一些相当令人难以置信的语法转换，对 javascript 编程语言所做的简化，由谷歌闭包编译器。
我的问题是 - 有没有什么东西可以为 Java 提供这些类型的语法转换？
We see in the following blog entry: http://blog.fogus.me/2011/07/21/compiling-clojure-to-javascript-pt1/ some pretty incredible syntax transformations, simplifications done to the javascript programming language, done by the Google Closure compiler.
My question is - is there something that provides these kinds of syntactic transformations for Java?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
Closure 编译器之所以如此工作，是因为 JavaScript 与 Java 不同，通常以源代码形式分发。因此，重命名变量和消除空格之类的操作不适用于 Java，因为 Java 应用程序通常作为字节码分发（通常打包在 JAR 文件中）。
至于其余的优化，Java 编译器和 Hotspot JVM 本身结合了许多非常擅长优化应用程序和提高性能的技术：其中许多技术就在您不知道的情况下发生了。
The Closure compiler works the way it does because JavaScript, unlike Java, is typically distributed in source form. So doing things like renaming variables and eliminating whitespace don't apply to Java, since Java applications are typically distributed as bytecode (often packaged in JAR files).
As for the rest of the optimization, the Java compiler and Hotspot JVM itself incorporate a number of techniques that are very good at optimizing your application and improving performance: many of them just happen without you knowing that they're there.
作为一般规则，Java 编译器可以/执行一些通常有用的优化来生成 JVM 代码。然后，JVM 中的 JIT 编译器在生成本机机器代码时会进行更多优化。由于这两者都是自动的并且对您来说是不可见的，因此您不会注意到，但您不需要明确地执行它们。
总有一些转换可能会在程序的上下文中完成，但 Java 编译器和 JIT 编译器无法知道要执行的转换。对于这些，您理想地需要某种源到源程序转换系统，它可以读取源代码，将其解析为某种工具内部结构（通常是 AST），应用您在此内部结构上定义的“令人难以置信的语法转换”，然后用您的语言重新生成源代码。
我们的DMS Software Reengineering Toolkit（商业）就是这样一个引擎；它可以处理多种语言。 DMS 有一个 Java 1.6 前端，它构建完整的符号表并提供控制和数据流分析，对于实现更复杂的转换是必要的。
免费（大学研究）替代方案是 Stratego 和 TXL，两者都有一些（我不知道）成熟的Java解析器，但绝对不提供符号表或任何类型的流分析，这意味着你必须构建这些或一个糟糕的近似你自己。有人可能会建议 ANTLR，它也有一个 Java 前端，可能构建 AST，很可能不构建符号表，并且不提供典型转换系统所做的其余机制（源到源转换、源文本的重新生成等）。
如果您对 Java 编译器的功能感到满意，则不需要任何这个。如果它还不够，那么你想要这样的东西。 [您提出这个问题的事实表明您对 Java 编译器不做的事情有所了解。愿意详细说明吗？]
As a general rule, the Java compiler can/does some generally useful optimizations to produce JVM code. The JIT compiler in the JVM then does more optimizations as it generates native machine code. Since both of these are automatic and invisible to you, you don't notice, but you don't need to do them explicitly.
There are always transformations that might be done in the context of your program that the Java compiler and the JIT compiler cannot know to do. For these you ideally want to some kind of source-to-source program transformation system, which can read source code, parse it to some kind of tool-internal structure (typically ASTs), apply "incredible syntax transformations" that you define on this internal structure, and then regenerate source code in your language.
Our DMS Software Reengineering Toolkit (commercial) is such an engine; it handles many languages. DMS has a Java 1.6 front end which builds full symbol tables and provides control and data flow analyses, necessary to enable more complex transformations.
Free (university research) alternatives are Stratego and TXL, both of which have Java parsers of some (unknown to me) maturity, but definitely do not provide symbol tables or any kind of flow analysis, meaning you have to build these or a bad approximation yourself. There are folks that may suggest ANTLR, which also has a Java front end, probably builds ASTs, very likely does not build symbol tables, and doesn't provide the rest of the machinery that typical transformation systems do (source-to-source transformations, regeneration of source text, etc.)
If you are happy with what the Java compiler does, you don't need any of this. If it doesn't do enough, then you want something like this. [The fact that you asked the question suggests you have some idea of something you want done that the Java compiler doesn't do. Care to elaborate?]
海事组织，不是真的。
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 编译器执行的高级优化涉及包含许多类的输入文件。
IMO, not really.
The Google Closure compiler takes Javascript as input and performs high level transformations of the (relatively semantically rich) Javascript AST.
The Java bytecode compilers could do, but apparently don't do much in the way of optimizing at the Java AST level. Instead, they leave most of the optimization to the JIT compiler ... which optimizes starting from the (relatively semantically poor) class file; i.e. bytecodes.
This makes it harder for the JIT compiler to do the kinds of optimizations that the Google Closure compiler could do.
So why is there isn't there an equivalent to Google Closure for Java? There are two possible reasons:
Because nobody has done it. (I can't recall any specific examples ...)
Because the opportunities for optimization are not there, for normal hand-written Java input.
Technical reasons (see below).
IMO it is mostly the second reason. The dynamic nature of Javascript and typical Javascript programs means that there are more opportunities for optimization by AST transformation, and that an AST-level optimizer will achieve more significant speedups for normal code.
Now, it may well be that the Java source code produced the Clojure compiler would present more opportunities for AST-level optimization. And it may be a good idea to revisit previous attempts at AST-level optimization for Java (assuming they existed).
The "technical reasons" I alluded to above include the following:
The presence of certain reflection and introspection facilities in Java are actually an impediment to optimization. For instance, the stated reason that Java compilers can't do tail call optimization is that it breaks Java code that relies no being able to look at the call stack. And one example is the security manager.
The Java bytecode compilers primarily operate at the level of individual compilation units; i.e. individual classes / interfaces / etc. The kind of high-level optimizations performed by the Google Closure compiler involve an input files contain many classes.