
J2cl: Transpile Java to JavaScript for Closure Compiler - robfig
https://github.com/google/j2cl
======
austincheney
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
> "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
>> 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.

Such ignorance is commonplace. I have seen so much evidence of basic ignorance
in so much code that I do not at all dispute what austincheney has said. The
worst problems appear in an area that was omitted from the list; concurrency.
Many, many "paid programmers" are oblivious to concurrency issues and produce
races and deadlocks throughout their work. The thought that anyone might
expect them to yield "thread safe" work prior to production deployment is
absurd.

As basic and simple minded as Java is, it is far beyond some large fraction of
the paid programmers using it.

If this offends you and you believe this is a world where such incompetence is
not tolerated please understand you are, respectfully, very wrong. The people
employing such "programmers" do not care, even when they are told and provided
irrefutable evidence. They want cheap. They want to check a "done" box and if
problems appear later they'll make more boxes. They simply don't care.

~~~
pjmlp
By my experience, the language being used is orthogonal to companies willing
to hire such low level devs out of the street.

~~~
topspin
The bulk of them are billed as high level devs complete with masters degrees
and provided under contract by body shops. They are not "out of the street."
They were "taught" java almost exclusively.

~~~
pjmlp
Exactly what I was referring to.

Out of the street devs, sold as capable of doing something.

A recurring pattern in offshoring consultancies.

And no, it isn't exclusive to Java.

------
tadeegan
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-co...](https://medium.com/@thomasdeegan/10-optimizations-closure-
compiler-can-do-and-uglify-friends-cant-6dca4232299f)

This website has Closure Compiler compiled by J2CL running in the browser
itself!

[https://closure-compiler-
debugger.appspot.com/j2cl_debugger....](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)

~~~
evmar
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.

------
pron
A recent blog post discussing some other ways to run Java in the browser:
[https://renato.athaydes.com/posts/comparing-jvm-
alternatives...](https://renato.athaydes.com/posts/comparing-jvm-alternatives-
to-js.html)

I currently use TeaVM and it's excellent, but I'll give J2CL a try.

~~~
vturner
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.

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

------
_bxg1
The webs we weave... so to speak.

------
cutler
Can this be made to work with Kotlin?

~~~
wtetzner
Doesn't Kotlin already have a JS backend?

~~~
cromwellian
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
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
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.

