Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

J2CL Now & Next #93

10 of 23 tasks
gkdn opened this issue May 27, 2020 · 11 comments
10 of 23 tasks

J2CL Now & Next #93

gkdn opened this issue May 27, 2020 · 11 comments


Copy link

gkdn commented May 27, 2020

By popular request, I am listing the things that J2CL team is actively working on apart from continuous improvements and maintenance and what to expect in the next quarters:

Last Edit: Aug 2, 2022


  • Improve WASM GC spec, tooling and J2CL experimental Wasm backend
  • Support Kotlin language


  • Reduce limitations on @JsEnums
  • Finalize supported Enum/EnumSet APIs
  • Investigate embedding GwtIncompatibleStripper step into J2CL
  • Implement testing support for Open Source
  • Add periodic auto-tagging for Open Source for versioned releases


  • Enable RTA pruning for Open Source development
  • Add ability to run JsInteropRestrictionChecker as an ErrorProne plugin
  • Optimize Dagger to be more efficient with J2CL
  • Switch default fronted from JDT to Javac
  • Remove boxing from long (similar to double/Double)
  • Support for Java 17

Completed in previous quarters

  • Java 11 support (completed, waiting Bazel release)
  • First-class support for JSR nullability
  • Optimize AutoValue to be more efficient with J2CL
  • Improve code generation Java enums to reduce code size
  • Add experimental Wasm backend
  • Switch to Bazel TreeArtifacts
  • Overhaul bridge calculate&creation to fix related bugs and reduce code size
  • Fix overflow for integer arithmetic
  • Improve JsCompiler optimizations
  • Switch to Bazelisk by default


The J2CL code is production ready and battle tested with Google Apps for years. Only open-source tooling is missing some workflows. All of our improvements to the released code are in sync with Google and you are getting the improvement at the same time as Google gets.

At the moment for J2CL, we are only planning to do dated releases (instead of semantic versioning like v1) and make more tools work in open source over time.

Copy link

rov63rus commented Sep 15, 2020

Are you planning gradle support ? Bazel is not known to any IDE.

Copy link

tbroyer commented Sep 15, 2020 ?
(my main problem with the IntelliJ IDEA plugin though is that it's currently not compatible with latest IDEA 2020.2: bazelbuild/intellij#1998)

Copy link

sgammon commented Dec 10, 2020

i would love to see some gRPC support on this list :)

Copy link

treblereel commented Dec 23, 2020

Are there any workarounds how to run tests, before j2cl_test ll be ported ? It's a critical feature

Copy link

rjahn commented Oct 15, 2021

any updates here?

Copy link
Member Author

gkdn commented Oct 15, 2021

I update it every now and then but comment date doesn't reflect that (you need to click edited to see the change dates).

Copy link

LifeIsStrange commented Dec 2, 2021

Any update on Kotlin support? That would be amazing and java projects are increasingly hybridized with Kotlin

Copy link
Member Author

gkdn commented Dec 14, 2021

We just started Kotlin work. Our goal is to have something usable by end of the year.

Copy link

LifeIsStrange commented Dec 14, 2021

@gkdn that is amazing to hear but Kotlin JS is officially developed and has an excellent and mature support for transpiling Kotlin to JS (and generating typescript types)
However while kotlin multiplarform/js is great, and while j2cl allow to transpile Java to js, I feel like the main area for improvement would be for J2CL to leverage existing Kotlin js transpiling ability and to be interoperable with the generated js from Java.
If you could work on making it easier to have hybrid Kotlin-Java projects that target js that would be amazing, maybe that the biggest issue is about IDE supports at the boundaries (Kotlin js will not allow calling java code even if this java code transpile to J2CL). Improving this IDE interop between Java and Kotlin JS should be possible in theory, either by contributing directly to the Kotlin js compiler or by making a Kotlin compiler plugin (note that the replacement API for the new Kotlin compiler (K2) is in active development
Also you might consider using arrow-meta which is a library that helps building compiler plugins.
BTW since you work at Google, maybe you could contact one of the official Google kotlin devs, as you can see here:
for some guidance.
The best would be to contact Roman Elizarov or to open a youtrack ticket for a collaboration :)
I really hope there is the possibility of making a synergy with JetBrains!
Anyway just my two cents on how to achieve the best of both worlds.

BTW: I concur that Gradle support would be a step in the right direction for adoption.

Copy link
Member Author

gkdn commented Dec 16, 2021

Our high demanding customers relies on very Closure style centric Google JavaScript stack (which J2CL is optimized for) and they count every single byte for performance. Unfortunately Kotlin/JS output doesn't match our needs and sometimes in a way that might be contradicting with the Kotlin open-source users needs who rely on different JavaScript stacks.

So for now our main focus we will be enabling Kotlin to those customers. Being said that I already met with Roman on this and we are in contact with JetBreains. We will be still looking into bringing the two worlds together in the long run.

Copy link

LifeIsStrange commented Dec 16, 2021

@gkdn I suppose you could apply a post processing step to the generated kotlin-js by feeding it to Closure. You could also work on improving the efficiency of the IR backend.
But sure feel free to implement your own incompatible transpiler.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
None yet

No branches or pull requests

7 participants