Is there an equivalent to Google Closure's optimisations for javascript, for Java?

Question

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?

Answer 1

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.

Answer 2

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?]

Answer 3

My question is - is there something that provides these kinds of syntactic transformations for Java?

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; ie 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; ie individual classes / interfaces / etc. The kind of high-level optimizations performed by the Google Closure compiler involve an input files contain many classes.