Make GWT fun again - what's the status of faster GWT compilation from scratch?

274 views
Skip to first unread message

Geoffrey De Smet

unread,
Aug 4, 2017, 3:37:12 AM8/4/17
to GWT Contributors
Currently we suffer a lot from time-consuming and memory-hungry GWT compilation on a big project, especially during a "mvn clean install", the GWT compilation takes several minutes.
GWT super dev mode does alleviate some of these problems sometimes, but when backend code changes, often the only reliable action is to restart the entire server.

Will J2CL and GWT 3 make GWT compilation scale better (faster and/or less memory-hungry for big projects)?
Is any active progress being made on these technologies?
Are there any examples out there with a big codebase so we can see the compilation performance difference in action?
Can we experiment with it on ours?

wkr,
Geoffrey

Jens

unread,
Aug 4, 2017, 4:06:23 AM8/4/17
to GWT Contributors

Will J2CL and GWT 3 make GWT compilation scale better (faster and/or less memory-hungry for big projects)?

Yes, J2CL creates one JS file per Java file. No optimizations, nothing, just simply converting from Java syntax to JavaScript ES6 classes. I think it has been said that it is roughly as fast as javac compiling a single java file to a class file. For production you would then optimize all these JS files using closure compiler.
 
Is any active progress being made on these technologies?
Are there any examples out there with a big codebase so we can see the compilation performance difference in action?
Can we experiment with it on ours?

 J2CL is in active development and I guess it will be open sourced this year. Once it is released you can play with it and once it is released we can see how GWT 3 will look like.

-- J.

Thomas Broyer

unread,
Aug 4, 2017, 6:43:07 AM8/4/17
to GWT Contributors


On Friday, August 4, 2017 at 9:37:12 AM UTC+2, Geoffrey De Smet wrote:
Currently we suffer a lot from time-consuming and memory-hungry GWT compilation on a big project, especially during a "mvn clean install", the GWT compilation takes several minutes.
GWT super dev mode does alleviate some of these problems sometimes, but when backend code changes, often the only reliable action is to restart the entire server.

That shouldn't necessarily mean recompiling the GWT app though.
 
Will J2CL and GWT 3 make GWT compilation scale better (faster and/or less memory-hungry for big projects)?

J2Cl should be really fast, but the Closure Compiler phase is likely to be the bottleneck. I don't have numbers though as I haven't experimented with it yet.
 
Is any active progress being made on these technologies?

Yes (on the J2Cl side; not GWT 3 yet, it's actually yet to be defined what exactly will be GWT 3: encapsulate J2Cl and Closure Compiler into a "monolithic" tool? or mostly just libraries to be used with J2Cl and Closure Compiler, probably along with Maven/Gradle/etc. plugins tying things together)
 
Are there any examples out there with a big codebase so we can see the compilation performance difference in action?
Can we experiment with it on ours?

No yet, but if you want an idea of compilation performance, find a JS project with an equivalent number of files and classes (actually, J2Cl produces at least two JS files per Java file, but one ES6 class per Java class) and run the Closure Compiler on it.
One thing we don't know yet how it'd work is "permutations": hopefully there shouldn't be "permutations" per browser anymore, but how about i18n? and then how to select the appropriate "permutation" at runtime?

Also, for development, there should hopefully be an equivalent to "draft mode" / "super dev mode" where generated sources are simply concatenated, without further processing (except maybe some basic minification). AFAIK, this is something they have in Closure Compiler that should be open sourced soonish.

That said, J2Cl / GWT 3 might require some specific project layout (it might become impossible to mix client and server code in the same Maven module; hopefully a split layout like in https://github.com/tbroyer/gwt-maven-archetypes will continue to work with minimal changes to the POMs) so the first thing in any case is to "clean up" existing codebases; and this hopefully could make your build more incremental, so you wouldn't need to recompile your GWT client code when you only changed server-side code.

For now, make sure you take full advantage of GWT incremental compilation and your build tool's incremental build support (Maven is "broken by design" on that front, but should work quite well nonetheless with recent plugin versions; but what I mean primarily is "don't 'clean'")
Reply all
Reply to author
Forward
0 new messages