> I fail to understand why the prerequisite of using bazel was enforced Bazel is enforced if you want to contribute to J2CL not if you want to use it. As Goktug mentioned in his post, J2CL has been built for our internal users first. So it's natural to first integrate it with Bazel as we use it internally and it's our domain of expertise. As any other project, we don't want to maintain different build files for building and developing J2CL. J2CL is a java application that takes java files as input and generates closure annotated js files. You need then to pass those generated js file to the javascript/closure pipeline. That part is slightly different for each build system and we rely on open source contributors to make the right decision.
That being said, we truly think J2CL can bring some added value to the opensource community and that people outside of Google (mainly GWT contributors) could be interested. You should just stop thinking that J2CL is intended to be the replacement of GWT. GWT 3.0 could use j2cl as main compiler or not. It will be up to the GWT steering committee to decide. On Tue, Jun 12, 2018 at 12:10 AM David Nouls <[email protected]> wrote: > Thanks for the update, > > I fail to understand why the prerequisite of using bazel was enforced and > why it seems to have such a big impact on opensourcing J2CL. > As far as I understand Google is probably the only company that uses > bazel, and internally that is not even the same product as the opensource > one. > > Does J2CL depend on Bazel somehow ? That sounds like a liability to me. > Newer versions of Gradle have a lot of optimisations and caching > implemented, so was it really worth the effort to use Bazel ? > On 12 Jun 2018, 08:54 +0200, 'Goktug Gokdogan' via GWT Contributors < > [email protected]>, wrote: > > *We recently sent an update on J2CL and we would like to cross post it to > GWT contributor list since there was recent questions about it. I would > like to also remind everybody that GWT3 != J2CL; GWT3 work is still ongoing > in the open source community and I will talk to steering committee to see > if an update on it could be provided as well.* > ---- > > *Since we gave access to more people, we thought that this would be a good > time to give you an update on J2CL; what is happening, if it is really a > thing or not and what to expect from it.* > > *First the good parts:* > > *1- J2CL is feature complete for a while and had a very strong traction in > Google in the last year.* > > *We got pretty big customers on board and some launched to production and > they are pretty happy about it. To name a few projects that are already > running J2CL code: New GMail, Inbox, Docs, Slides. And more are coming.* > > *We could not have achieved this with GWT since our customers apps have > very strict expectations on code size/performance and interoperation with > their existing JavaScript stack. And this is why we built J2CL in the first > place.* > > *2- J2CL has improved on code size compared to already quite performant > GWT compiler.* > > *The last time I checked it was around 5-10% code size reduction and we > will continue working on that.* > > *3- Optimized compiles improved by 50% and it is possible to get a couple > of second refresh times for development.* > > > *And now the “could be better” parts :)* > > *1- Open-source build is not fully working* > > *J2CL is highly optimized for Google infrastructure and scales very well > with Bazel. There are multiple reasons for that:* > > *- Bazel works very well as a cross-platform build solution. You can build > your Android, iOS and Web application together with Bazel.* > > *- Bazel has a very good caching/scaling architecture and we already > designed J2CL based on that.* > > *- Bazel is our only expertise on build systems so we can only ensure > developers gets a good development experience using Bazel.* > > *For pure J2CL experience in open source, we decided early on to rely on > Bazel and made it a prerequisite for open-sourcing it.* > > *However, our internal build macros used things that are only available > internally so we need to clean and port to a more proper solution that > could also work well for open-source. And during that process we keep > hitting limitations that block us and cause delays. Also please keep in > mind that J2CL’s success is highly related to its internal success and we > were busy helping internal customers to have successful production launches > so we didn't have much bandwidth either.* > > *On the bright side, most of the blocking issues are getting resolved and > we had progress in the last couple of months and we are prioritizing this > even further.* > > *(Note that this doesn’t mean you will be *required* to use Bazel for J2CL > and our contributors are already working on Maven/Gradle solutions.)* > > *2- For now your mileage may vary w.r.t performance* > > *Even though optimized compiles are much better for Google, I am not sure > how this will translate to open- source since the two compilers scale > differently and historically open source users got better performance out > of GWT than we did internally. However I'm optimistic on this in the long > run.* > > *For development edit/refresh cycles, it is hard to beat GWT’s SDM since > it is already designed to do the very minimal things required to serve > development code. Being said that it is still possible to have good refresh > times using something called 'iblaze' which is essentially a file watcher > that triggers a warm transpiler and code bundler where we could do caching.* > > *One worry I have here is, we use some tools that does code pruning during > build which helps some with the performance, and those tools are not > available for open source. Something we will eventually look at but not > very soon.* > > > *Anyway, this is the quick summary of how things are and I hope it sheds > some light to the questions.* > > -- > You received this message because you are subscribed to the Google Groups > "GWT Contributors" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAN%3DyUA1idZ%3DcM77U%2BrbShH7%2Brhv7kS%3Dj7uz%2BJRCPoCgjcu06gQ%40mail.gmail.com > <https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAN%3DyUA1idZ%3DcM77U%2BrbShH7%2Brhv7kS%3Dj7uz%2BJRCPoCgjcu06gQ%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > > -- > You received this message because you are subscribed to the Google Groups > "GWT Contributors" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/google-web-toolkit-contributors/f1a3ea0f-03d1-4e33-82a8-61330820895c%40Spark > <https://groups.google.com/d/msgid/google-web-toolkit-contributors/f1a3ea0f-03d1-4e33-82a8-61330820895c%40Spark?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "GWT Contributors" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/CABb_3%3D5hC5s_oA_20QH1agS9wJnRWAcrLL%2BgRVX_Vy%3DMuGLPMg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
