6 ms·

J2cl: Transpile Java to JavaScript for Closure Compiler

73 points by robfig 7y ago

tadeegan 7y ago
I used to work on this. Happy to answer questions. Here is a good article about Closure Compiler optimizations which J2CL uses as its optimizing compiler: https://medium.com/@thomasdeegan/10-optimizations-closure-compiler-can-do-and-uglify-friends-cant-6dca4232299f https://medium.com/@thomasdeegan/10-optimizations-closure-co... This website has Closure Compiler compiled by J2CL running in the browser itself! https://closure-compiler-debugger.appspot.com/j2cl_debugger.html#input0%3Dclass%2520A%2520%257B%250A%2520%2520method%28%29%2520%257B%250A%2520%2520%2520%2520console.log%28%2522A%2522%29%253B%250A%2520%2520%257D%250A%257D%250A%250Aclass%2520B%2520%257B%250A%2520%2520method%28%29%2520%257B%250A%2520%2520%2520%2520console.log%28%2522B%2522%29%253B%250A%2520%2520%257D%250A%257D%250A%250A%252F**%2520%2540return%2520%257BA%257D%2520*%252F%250Afunction%2520getA%28%29%2520%257B%250A%2520%2520return%2520new%2520A%28%29%253B%250A%257D%250A%250Alet%2520a%2520%253D%2520getA%28%29%253B%250Alet%2520b%2520%253D%2520new%2520B%28%29%253B%250A%250A%252F%252F%2520Statically%2520infer%2520A%2523method%2520or%2520B%2523method%2520in%2520a%2520dynamic%2520language%250Aa.method%28%29%253B%250Ab.method%28%29%253B%26conformanceConfig%26externs%3Dvar%2520console%2520%253D%2520%257B%257D%253B%250A%252F**%2520%2540param%2520%257Bstring%257D%2520s*%252F%250Aconsole.log%2520%253D%2520function%28s%29%2520%257B%257D%253B%26refasterjs-template%26TRANSPILE%3Dtrue%26CHECK_SYMBOLS%3Dtrue%26CHECK_TYPES%3Dtrue%26COMPUTE_FUNCTION_SIDE_EFFECTS%3Dtrue%26FOLD_CONSTANTS%3Dtrue%26DEAD_ASSIGNMENT_ELIMINATION%3Dtrue%26INLINE_CONSTANTS%3Dtrue%26INLINE_FUNCTIONS%3Dtrue%26COALESCE_VARIABLE_NAMES%3Dtrue%26INLINE_VARIABLES%3Dtrue%26FLOW_SENSITIVE_INLINE_VARIABLES%3Dtrue%26SMART_NAME_REMOVAL%3Dtrue%26REMOVE_DEAD_CODE%3Dtrue%26REMOVE_UNUSED_PROTOTYPE_PROPERTIES%3Dtrue%26REMOVE_UNUSED_CLASS_PROPERTIES%3Dtrue%26REMOVE_UNUSED_VARIABLES%3Dtrue%26COLLAPSE_VARIABLE_DECLARATIONS%3Dtrue%26COLLAPSE_ANONYMOUS_FUNCTIONS%3Dtrue%26CONVERT_TO_DOTTED_PROPERTIES%3Dtrue%26LABEL_RENAMING%3Dtrue%26COLLAPSE_PROPERTIES%3Dtrue%26DEVIRTUALIZE_PROTOTYPE_METHODS%3Dtrue%26DISAMBIGUATE_PROPERTIES%3Dtrue%26AMBIGUATE_PROPERTIES%3Dtrue%26VARIABLE_RENAMING%3Dtrue%26PROPERTY_RENAMING%3Dtrue%26OPTIMIZE_CALLS%3Dtrue%26OPTIMIZE_PARAMETERS%3Dtrue%26OPTIMIZE_RETURNS%3Dtrue%26CLOSURE_PASS%3Dtrue%26CROSS_MODULE_CODE_MOTION%3Dtrue%26CROSS_MODULE_METHOD_MOTION%3Dtrue%26includeDefaultExterns%3Dtrue https://closure-compiler-debugger.appspot.com/j2cl_debugger....
- evmar 7y ago
  I've been attempting to create a benchmark for comparing Closure against other options on more real-world code: https://evmar.github.io/js-min-bench/ https://evmar.github.io/js-min-bench/ What I've discovered that has changed recently is that the Graal-compiled Closure is now as fast as other tools, but also that other tools seem to produce about as good of code. I suspect J2CL might particularly benefit from Closure in that it likely generates a lot more dead code.
austincheney 7y ago
While I suspect this could be much better than Google Web Toolkit the same problems will continue to exist. The primary problem was Java developers compiling code where they had no idea what the output was doing, which becomes a problem when they encounter a defect or fail to achieve a business requirement. The added problem with GWT is that no JavaScript developer wanted to touch that garbage code. Many Java developers I worked with in the past had no understanding of callbacks, asynchronous logic, events, recursion, scope, closure, array notation (Java has this), or high speed data via random access hash maps (Java has this too). This becomes problematic because some Java concepts do not exist in JavaScript and some JavaScript concepts do not exist in Java. Often times the Java developer will still need help from a JavaScript developer to achieve basic business requirements. Also calling Closure Compiler generated code the best of JavaScript is highly debatable. If as a Java developer you want greater expressive freedom and more functional code like you can do in JavaScript, without sacrificing performance, you are better off writing your code in Scala. If as a JavaScript developer you want a compiler to validate your code against strict type checks you are better off writing your code in TypeScript. In the past the only business objective behind GWT was solving for labor shortages. Java developers were common and typically competent. JavaScript developers were often less trusted or harder to find. I wonder if this is still a factor.
- RandyRanderson 7y ago
  > "Many Java developers I worked with in the past had no understanding of callbacks, asynchronous logic, events, recursion, scope, closure, array notation (Java has this), or high speed data via random access hash maps (Java has this too)..." What??? I find it unlikely that ANY paid "programmer" in ANY language would not have at least a decent grasp of most of those things in order to produce any correct program at all. No, I think it's more likely that you're involved in what I've often speculated is a physical manifestation of a finite monkey experiment. The remainder of an drug-fueled late-night VC bet, no doubt. The other side, of course, is likely trying to corner the cavendish market right now - starve you guys out! Stay strong - I believe in you.
  - topspin 7y ago
cutler 7y ago
Can this be made to work with Kotlin?
- cromwellian 7y ago
  Someone at some point (was it an intern or OSS contributor? I forgot, or maybe I'm misremembering) made a prototype Kotlin->Java J2CL code transpiler. Basically, you just need a Kotlin backend that generates Java source instead of Bytecode. Kotlin hired the guy who wrote the TeaVM, so I think they are focusing on bytecode translation approaches to JS. We considered this for J2CL but ultimately decided to use JDT parsing from Source, because with bytecode you lose some information you have in the Java AST that requires reconstructing it. Also, Kotlin's runtime is quite large, and if you were trying to compile Kotlin -> J2CL you'd want a customized runtime that relies on JsInterop and Elemental2 to get the smallest possible code size.
- wtetzner 7y ago
  Doesn't Kotlin already have a JS backend?
  - cromwellian 7y ago
    Yes, but it's somewhat bloated. J2CL+Closure optimizes code better. KotlinJS requires inclusion of a bulky runtime. Last time I checked, it doesn't do dead code elimination well (on the runtime). Closure Compiler was built to optimize even untyped JS, and the way hybrid J2CL/JS apps work, extern files assist the compiler in "safely" doing global optimizations. It's not perfect, and you can confuse the compiler (but you can do the same thing in Java with reflection + Proguard), but it works well enough if you know what to watch out for.
tannhaeuser 7y ago
I've read J2CL vs. GWT? in the readme but still do not quite understand how J2CL is different. Hasn't gwt transpiled Java to JavaScript for many years? What is meant by closure-style JavaScript? That it uses jsdoc type annotations and goog.require etc.?
- cromwellian 7y ago
  GWT was a transpiler, optimizing Java compiler, optimizing JS compiler (had two backends inside of it), a container for hosted development environment, an annotation processor environment (before Java annotation processors), an SDK with a huge number of APIs, a Linker, a UI toolkit, and on and on, it basically was an end to end build environment. J2CL is a transpiler, from Java to Closure annotated JS. It does no optimizations. It has no APIs. It only deals with standard Java inputs, everything else: SDK, debugger, optimizer, build time processing, edit/refresh, etc all has to come from the rest of the toolchain. GWT was monolithic. J2CL is a step in your build file. J2CL also produces smaller code than GWT, compiles faster, and fits into existing JS ecosystem a lot better. It's not hard to say, wire up J2CL code with any arbitrary TS or JS node module.
pron 7y ago
A recent blog post discussing some other ways to run Java in the browser: https://renato.athaydes.com/posts/comparing-jvm-alternatives-to-js.html https://renato.athaydes.com/posts/comparing-jvm-alternatives... I currently use TeaVM and it's excellent, but I'll give J2CL a try.
- vturner 7y ago
  The rise of the various open source solutions is relieving but I don't feel confident recommending them yet over say TypeScript. I wish Oracle would see the opportunity here to win back some space of user apps where Java had mindshare and make a compile target. It's not easy I know but still I wish.
- brabel 7y ago
  Yep, and the latest unstable TeaVM versions are showing huge improvements over the figures shown in that blog post: https://github.com/renatoathaydes/jvm-alternatives-to-js/issues/1 https://github.com/renatoathaydes/jvm-alternatives-to-js/iss...
fulafel 7y ago
Is this a source-level tool or could it be used to compile other JVM languages too?
_bxg1 7y ago
The webs we weave... so to speak.

73 points by robfig 7y ago

I used to work on this. Happy to answer questions. Here is a good article about Closure Compiler optimizations which J2CL uses as its optimizing compiler: https://medium.com/@thomasdeegan/10-optimizations-closure-compiler-can-do-and-uglify-friends-cant-6dca4232299f https://medium.com/@thomasdeegan/10-optimizations-closure-co... This website has Closure Compiler compiled by J2CL running in the browser itself! https://closure-compiler-debugger.appspot.com/j2cl_debugger.html#input0%3Dclass%2520A%2520%257B%250A%2520%2520method%28%29%2520%257B%250A%2520%2520%2520%2520console.log%28%2522A%2522%29%253B%250A%2520%2520%257D%250A%257D%250A%250Aclass%2520B%2520%257B%250A%2520%2520method%28%29%2520%257B%250A%2520%2520%2520%2520console.log%28%2522B%2522%29%253B%250A%2520%2520%257D%250A%257D%250A%250A%252F**%2520%2540return%2520%257BA%257D%2520*%252F%250Afunction%2520getA%28%29%2520%257B%250A%2520%2520return%2520new%2520A%28%29%253B%250A%257D%250A%250Alet%2520a%2520%253D%2520getA%28%29%253B%250Alet%2520b%2520%253D%2520new%2520B%28%29%253B%250A%250A%252F%252F%2520Statically%2520infer%2520A%2523method%2520or%2520B%2523method%2520in%2520a%2520dynamic%2520language%250Aa.method%28%29%253B%250Ab.method%28%29%253B%26conformanceConfig%26externs%3Dvar%2520console%2520%253D%2520%257B%257D%253B%250A%252F**%2520%2540param%2520%257Bstring%257D%2520s*%252F%250Aconsole.log%2520%253D%2520function%28s%29%2520%257B%257D%253B%26refasterjs-template%26TRANSPILE%3Dtrue%26CHECK_SYMBOLS%3Dtrue%26CHECK_TYPES%3Dtrue%26COMPUTE_FUNCTION_SIDE_EFFECTS%3Dtrue%26FOLD_CONSTANTS%3Dtrue%26DEAD_ASSIGNMENT_ELIMINATION%3Dtrue%26INLINE_CONSTANTS%3Dtrue%26INLINE_FUNCTIONS%3Dtrue%26COALESCE_VARIABLE_NAMES%3Dtrue%26INLINE_VARIABLES%3Dtrue%26FLOW_SENSITIVE_INLINE_VARIABLES%3Dtrue%26SMART_NAME_REMOVAL%3Dtrue%26REMOVE_DEAD_CODE%3Dtrue%26REMOVE_UNUSED_PROTOTYPE_PROPERTIES%3Dtrue%26REMOVE_UNUSED_CLASS_PROPERTIES%3Dtrue%26REMOVE_UNUSED_VARIABLES%3Dtrue%26COLLAPSE_VARIABLE_DECLARATIONS%3Dtrue%26COLLAPSE_ANONYMOUS_FUNCTIONS%3Dtrue%26CONVERT_TO_DOTTED_PROPERTIES%3Dtrue%26LABEL_RENAMING%3Dtrue%26COLLAPSE_PROPERTIES%3Dtrue%26DEVIRTUALIZE_PROTOTYPE_METHODS%3Dtrue%26DISAMBIGUATE_PROPERTIES%3Dtrue%26AMBIGUATE_PROPERTIES%3Dtrue%26VARIABLE_RENAMING%3Dtrue%26PROPERTY_RENAMING%3Dtrue%26OPTIMIZE_CALLS%3Dtrue%26OPTIMIZE_PARAMETERS%3Dtrue%26OPTIMIZE_RETURNS%3Dtrue%26CLOSURE_PASS%3Dtrue%26CROSS_MODULE_CODE_MOTION%3Dtrue%26CROSS_MODULE_METHOD_MOTION%3Dtrue%26includeDefaultExterns%3Dtrue https://closure-compiler-debugger.appspot.com/j2cl_debugger....

evmar 7y ago
I've been attempting to create a benchmark for comparing Closure against other options on more real-world code: https://evmar.github.io/js-min-bench/ https://evmar.github.io/js-min-bench/ What I've discovered that has changed recently is that the Graal-compiled Closure is now as fast as other tools, but also that other tools seem to produce about as good of code. I suspect J2CL might particularly benefit from Closure in that it likely generates a lot more dead code.

austincheney 7y ago

While I suspect this could be much better than Google Web Toolkit the same problems will continue to exist. The primary problem was Java developers compiling code where they had no idea what the output was doing, which becomes a problem when they encounter a defect or fail to achieve a business requirement. The added problem with GWT is that no JavaScript developer wanted to touch that garbage code. Many Java developers I worked with in the past had no understanding of callbacks, asynchronous logic, events, recursion, scope, closure, array notation (Java has this), or high speed data via random access hash maps (Java has this too). This becomes problematic because some Java concepts do not exist in JavaScript and some JavaScript concepts do not exist in Java. Often times the Java developer will still need help from a JavaScript developer to achieve basic business requirements. Also calling Closure Compiler generated code the best of JavaScript is highly debatable. If as a Java developer you want greater expressive freedom and more functional code like you can do in JavaScript, without sacrificing performance, you are better off writing your code in Scala. If as a JavaScript developer you want a compiler to validate your code against strict type checks you are better off writing your code in TypeScript. In the past the only business objective behind GWT was solving for labor shortages. Java developers were common and typically competent. JavaScript developers were often less trusted or harder to find. I wonder if this is still a factor.

RandyRanderson 7y ago
> "Many Java developers I worked with in the past had no understanding of callbacks, asynchronous logic, events, recursion, scope, closure, array notation (Java has this), or high speed data via random access hash maps (Java has this too)..." What??? I find it unlikely that ANY paid "programmer" in ANY language would not have at least a decent grasp of most of those things in order to produce any correct program at all. No, I think it's more likely that you're involved in what I've often speculated is a physical manifestation of a finite monkey experiment. The remainder of an drug-fueled late-night VC bet, no doubt. The other side, of course, is likely trying to corner the cavendish market right now - starve you guys out! Stay strong - I believe in you.
- topspin 7y ago

cutler 7y ago

Can this be made to work with Kotlin?

cromwellian 7y ago
Someone at some point (was it an intern or OSS contributor? I forgot, or maybe I'm misremembering) made a prototype Kotlin->Java J2CL code transpiler. Basically, you just need a Kotlin backend that generates Java source instead of Bytecode. Kotlin hired the guy who wrote the TeaVM, so I think they are focusing on bytecode translation approaches to JS. We considered this for J2CL but ultimately decided to use JDT parsing from Source, because with bytecode you lose some information you have in the Java AST that requires reconstructing it. Also, Kotlin's runtime is quite large, and if you were trying to compile Kotlin -> J2CL you'd want a customized runtime that relies on JsInterop and Elemental2 to get the smallest possible code size.
wtetzner 7y ago
Doesn't Kotlin already have a JS backend?
- cromwellian 7y ago
  Yes, but it's somewhat bloated. J2CL+Closure optimizes code better. KotlinJS requires inclusion of a bulky runtime. Last time I checked, it doesn't do dead code elimination well (on the runtime). Closure Compiler was built to optimize even untyped JS, and the way hybrid J2CL/JS apps work, extern files assist the compiler in "safely" doing global optimizations. It's not perfect, and you can confuse the compiler (but you can do the same thing in Java with reflection + Proguard), but it works well enough if you know what to watch out for.

tannhaeuser 7y ago

I've read J2CL vs. GWT? in the readme but still do not quite understand how J2CL is different. Hasn't gwt transpiled Java to JavaScript for many years? What is meant by closure-style JavaScript? That it uses jsdoc type annotations and goog.require etc.?

cromwellian 7y ago
GWT was a transpiler, optimizing Java compiler, optimizing JS compiler (had two backends inside of it), a container for hosted development environment, an annotation processor environment (before Java annotation processors), an SDK with a huge number of APIs, a Linker, a UI toolkit, and on and on, it basically was an end to end build environment. J2CL is a transpiler, from Java to Closure annotated JS. It does no optimizations. It has no APIs. It only deals with standard Java inputs, everything else: SDK, debugger, optimizer, build time processing, edit/refresh, etc all has to come from the rest of the toolchain. GWT was monolithic. J2CL is a step in your build file. J2CL also produces smaller code than GWT, compiles faster, and fits into existing JS ecosystem a lot better. It's not hard to say, wire up J2CL code with any arbitrary TS or JS node module.

pron 7y ago

A recent blog post discussing some other ways to run Java in the browser: https://renato.athaydes.com/posts/comparing-jvm-alternatives-to-js.html https://renato.athaydes.com/posts/comparing-jvm-alternatives... I currently use TeaVM and it's excellent, but I'll give J2CL a try.

vturner 7y ago
The rise of the various open source solutions is relieving but I don't feel confident recommending them yet over say TypeScript. I wish Oracle would see the opportunity here to win back some space of user apps where Java had mindshare and make a compile target. It's not easy I know but still I wish.
brabel 7y ago
Yep, and the latest unstable TeaVM versions are showing huge improvements over the figures shown in that blog post: https://github.com/renatoathaydes/jvm-alternatives-to-js/issues/1 https://github.com/renatoathaydes/jvm-alternatives-to-js/iss...

fulafel 7y ago

Is this a source-level tool or could it be used to compile other JVM languages too?

_bxg1 7y ago

The webs we weave... so to speak.