What is the plan with Kotlin?

[sgammon]

I have been following (as best I can from the outside) the work on J2KT. But I don't quite understand how this will interact with J2CL within the context of solutions like Kotlin/JS.

After playing with Kotlin/JS, I am also a bit disappointed in the output from the compiler, as mentioned here. So I understand the reasoning behind choosing to build and use a toolchain separately.

But, does that mean that we would be writing Kotlin that, at a source level (not IR level), translates to JS via J2KT? In that case, is it translating in a Closure JS-compatible manner, so as to be compatible with advanced compilation through Closure Compiler?

Or, if not that, how does Kotlin factor into the dev flow? Thank you in advance for any guidance.

Further background / motivations

The question behind the post is really whether the same Kotlin code could be usable from J2KT or Kotlin/JS, I suppose. I realize that's a bit weird, but consider the following use case:

Within the same mono-repo, we have:

• React webapp. Although the Kotlin/JS compiler produces suboptimal ES5 code by 2022 standards, it does work, and unifying frontend and backend languages is important to us, so we choose the Kotlin/JS side because J2KT working well with React is probably not going to happen (at least easily). Kotlin/JS has strong support for this via the Kotlin wrappers.

• Chrome extension. In this case, we want to leverage Bazel, Protobuf, and J2CL/J2KT to get a really clean type-checked environment.

• Server app. We have an API running on top of the protos via gRPC, built again via Kotlin, but now server-side.

With this arrangement of modules, it would be tempting to leverage Kotlin Multiplatform to share common Kotlin objects between the server and the frontend. But this complicates interaction with the 2nd case via Bazel/J2KT, right?

Would there be a case, in J2KT, where the same objects could be used in all the above circumstances? Does KSP, Kotlin's new annotation processing system which supports Multiplatform, factor into this at all?

[gkdn]

There are 2 different things here that might have caused confusion.

J2KT is a tool to translate Java to Kotlin in a semantically correct way with minimal user intervention. The idea is, you can take any Java source and translate that to Kotlin source (on the fly or offline). When it is finished, it could be helpful to mass migrate big code bases from Java to Kotlin (for example to take benefit from KMP).
This tool is being developed on top of J2CL however it doesn't conceptually fit and should not be considered an integral part of J2CL project (that's why there are no references to it in the roadmap).

There is another ongoing project to make J2CL understand from Kotlin (as in ability to compile Kotlin source code) and will produce the output that J2CL is producing today for Java.
This will let you have Kotlin/Java mixed codebase and compile into performant/scalable JavaScript. This is not a separate tool than the J2CL itself but sometimes this capability is referred as K2CL or Kotlin/Closure. It will take at least couple of quarters to have something meaningful available here.
(Unfortunately ongoing work here is not completely visible externally as we needed to exclude some packages as it was breaking the open-source builds)

[sgammon]

I see. Thank you @gkdn, that does clear things up quite a bit. When K2CL is closer to stable, do you anticipate that the Kotlin code it would process / support would be compatible, or at least, not incompatible with Kotlin/JS?

Kotlin/JS is mostly vanilla Kotlin, with the external declaration, dynamic type, and some annotations thrown in here or there. I think they are processing these with KSP.

So, in theory, some eventual K2CL tool would not be offended to encounter these (regular) Kotlin annotations, so long as the language extensions (external / dynamic) don't break things in K2CL.

I realize J2CL's main stakeholders are inside Google and care a lot more about Closure integration than use from Kotlin. But if both could be achieved, I think J2CL would find a much broader use case and support system. Thanks again for answering my question... the path described by you here leaves me hopeful :)

[sgammon]

Also, there are some codebases I know that might like to leverage J2KT for the use case described here. If there are any docs for that (all good if not) I'd love to take a look and see if it could be useful to us.

[gkdn]

With Kotlin/JS compatibility, are you referring understanding Kotlin's JS related constructs?
Ideally yes but we will start looking into that in Q4 and see how much compatibility we could achieve there. But at minimal there could be some problems like existing code's expectations might not match Closure's externs.
However if you are referring Kotlin/JS produced code working with J2CL/JS code in a seamless way, I don't think that will ever work.

re. J2KT; currently it works like j2cl_library; e.g. you can have a j2kt_native_library supplied with Java sources and it will produce Kotlin/Native compatible target that you can depend from KT native targets (similar to how J2CL does Java to JS but in this case the output is Kotlin). It is mostly an experiment at this point; we will very likely share more about it when it gets more mature.

[sgammon]

I understand that J2CL/K2CL and Kotlin/JS (KJS for short) won't ever be binary compatible. That's okay. In the use case described above, I'm merely using the same sources to produce different J2CL and KJS targets, which happen to share some subset of sources.

For example, maybe we declare some common data objects, so that our KJS-based webapp can communicate via JSON or proto with our K2CL Chrome extension. But in every case, there would have to be a serialization / data-boundary there, because I wouldn't expect K2CL and KJS to produce output that "works together" as sources.

I am privately hopeful that Kotlin's move to an IR-based frontend compiler simplifies such cases in the future, because, theoretically, it could serve as a common precursor to Closure type definitions, TS definitions, and KWrapper definitions. So long as those externs/declarations stay in sync, maybe it's possible. But I'm not even reaching for that :) only for sharing at a source level to simplify keeping object structures in sync across targets.

[tbroyer]

Probably related: https://www.youtube.com/watch?v=o14wGByBRAQ

Kotlin is now the recommended programming language for server-side JVM usage at Google, set to replace Java while still providing access to a large existing Java ecosystem.

[sgammon]

very cool @tbroyer, thank you for sharing

[sgammon]

that's actually huge

[gkdn]

Yes the video is highly related to the work here however the quote from the video description is not accurate; I'm not sure where that is coming form.