Sunday, June 12, 2016

Re: Closure compiler removal ?

1. Is specifying -optimte 9 good enough to be the only one left?

AFAICT optimize 9 is the default anyways. Currently the values are used the following way:
  • 0: automatically used when -draftCompile is used or when configured manually.
  • 1 - 8: maximal amount of optimization passes for the Java AST and the JS AST. If change rate between passes is below 0.01 then optimization will stop.
  • 9: Apply 100 optimization passes and only abort earlier if change rate between passes is 0.
So when you use -optimize 9 there is probably not much left to optimize from a GWT compiler point of view ;-)

2. The reason for the removal states that it never worked with source maps, but source maps are only useful during development, when noone uses optimization?

I was a bit surprised too about the removal, but I am pretty sure its not just about source map issues. If I remember correctly the compile report did not work too when using closure compiler backend. But I never really used it so maybe I am wrong. I have never seen reasonable code size reduction when trying it on a large GWT app and thus avoided the risk of using an unfinished, experimental feature. It simply wasn't worth it for me.

It would have been nice if the closure integration would have understood the JS import of 3rd party GWT wrapper libraries as thats still a major pain point in GWT. Use a lot of wrapper libraries for GWT and your code size will be pretty large, as GWT can not optimize that external JS to only what you need. At least you won't have that issue with J2CL + JsInterop anymore.

If you want to continue use that closure feature of GWT, just fork GWT and revert the change.

-- J.

You received this message because you are subscribed to the Google Groups "GWT Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to
To post to this group, send email to
Visit this group at
For more options, visit

No comments:

Post a Comment