Open
Description
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: Dec 3, 2024
Now
- Support for Java 21Switch default fronted from JDT to JavacOpen-source tooling to enable Kotlin support
Next
- Implement TestSuite support for Open SourceReduce limitations on @JsEnumsFinalize supported Enum/EnumSet APIsAdd periodic auto-tagging for Open Source for versioned releases
Later
- Enable RTA pruning for Open Source developmentInvestigate embedding GwtIncompatibleStripper step into J2CLAdd ability to run JsInteropRestrictionChecker as an ErrorProne pluginOptimize Dagger to be more efficient with J2CLRemove boxing from long (similar to double/Double)
Completed in previous quarters
- Modular compilation for WasmImprove Wasm GC spec, tooling and J2CL experimental Wasm backendImplement testing support for Open SourceJava 11 support (completed, waiting Bazel release)First-class support for JSR nullabilityOptimize AutoValue to be more efficient with J2CLImprove code generation Java enums to reduce code sizeAdd experimental Wasm backendSwitch to Bazel TreeArtifactsOverhaul bridge calculate&creation to fix related bugs and reduce code sizeFix overflow for integer arithmeticImprove JsCompiler optimizationsSwitch to Bazelisk by default
Note:
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.
Activity
rov63rus commentedon Sep 15, 2020
Are you planning gradle support ? Bazel is not known to any IDE.
tbroyer commentedon Sep 15, 2020
https://docs.bazel.build/versions/master/ide.html ?
(my main problem with the IntelliJ IDEA plugin though is that it's currently not compatible with latest IDEA 2020.2: bazelbuild/intellij#1998)
sgammon commentedon Dec 10, 2020
i would love to see some gRPC support on this list :)
treblereel commentedon Dec 23, 2020
Are there any workarounds how to run tests, before j2cl_test ll be ported ? It's a critical feature
rjahn commentedon Oct 15, 2021
any updates here?
gkdn commentedon Oct 16, 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).LifeIsStrange commentedon Dec 3, 2021
Any update on Kotlin support? That would be amazing and java projects are increasingly hybridized with Kotlin
gkdn commentedon Dec 14, 2021
We just started Kotlin work. Our goal is to have something usable by end of the year.
LifeIsStrange commentedon Dec 15, 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 https://youtrack.jetbrains.com/issue/KT-49508
)
Also you might consider using arrow-meta which is a library that helps building compiler plugins.
https://github.com/arrow-kt/arrow-meta
BTW since you work at Google, maybe you could contact one of the official Google kotlin devs, as you can see here: https://kotlinlang.org/docs/kotlin-foundation.html#current-personnel
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.
gkdn commentedon 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.
LifeIsStrange commentedon 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.
treblereel commentedon Oct 23, 2022
@gkdn just in case, do you have any updates about
testing support for Open Source
?gkdn commentedon Oct 26, 2022
We have an intern working on it at the moment but we will see how it will turn out.
treblereel commentedon Oct 26, 2022
ok, and i suppose you have a deadline right ?
gkdn commentedon Oct 26, 2022
Should be within 2 months; if the project is successful.
treblereel commentedon Feb 2, 2023
It looks like it failed ... So pity :(
gkdn commentedon Feb 4, 2023
Actually basic unit testing support is released, sample app and getting started code is updated accordingly.
I haven't closed the task since it still doesn't support test suites but I will update the notes.
Edit: updated
treblereel commentedon Jan 31, 2024
@gkdn Do you plan to add support for the following methods from Java 9-11?
Stream: takeWhile, dropWhile, ofNullable, and iterate
String: isBlank, lines, repeat, strip, stripLeading, and stripTrailing
List/Set/Map: copyOf
Collectors: toUnmodifiable*
And if not, can we make a PR?
rluble commentedon Feb 1, 2024
We do accept contributions for missing jre methods.
Note that the implementations need to :
Isn't
String.repeat
is already in the JRE?niloc132 commentedon Feb 1, 2024
String.repeat
is indeed already implemented - but can you direct us how to run its tests? (I assume tests are required for such submissions, even though it wasn't on your list ;). )I see that
jre/javatests/com/google/j2cl/jre/java/lang/StringTest.java
has atestRepeat
method, but there don't seem to be any bazel targets to run individual test classes. #93 (comment) says (and seems to still be correct) that suites cannot run, and onlyjre/javatests/com/google/j2cl/jre/LangSuite.java
references StringTest.Here's the other things I tried, just in case I missed the obvious:
I noticed that LangSuite is referenced by the
Lang
j2cl_multi_test
in jre/javatests/BUILD`, but running that results inTypically when we see
//javascript
labels, or references at all to jscompiler, it means that this isn't available to be run outside of Google. Removing that import lineand all of the conformance test wiring that depends on it at least advances us to a new error:
Fortunately this is also not terrible to fix: there are two separate
load()
calls forclosure_js_binary
- removing the second one still leaves the first (though to just runLang
, I've commented out both of them).Next, I was getting this error:
It looks like
j2cl_multi_test
itself isn't able to run in open source due toJ2KT-NATIVE
platform not being populated? The code only has branches forCLOSURE
andWASM
. Next I took the drastic step of removing allj2cl_multi_test
(getting past the point of what I could comfortably suggest might even make sense to commit...), and instead wrote a custom test target:This hit compile errors, oddly - it seems that
emul_tests_lib
itself isn't set up properly? How can this run inside of Google at all? Or do you have entirely separate BUILD files (not just BUILD vs BUILD.bazel), and the checked in BUILD is never used?To fix, I changed my approach, not trying to run tests at all any more, but just get them to build, via
bazel build //jre/javatests:emul_tests_lib
.First I had to add
//third_party:jspecify_annotations-j2cl
to the deps list. Next, it seems that the list of disabled errorprone checks inemul_tests_lib
is inconsistent with currently checked-in code -TreeMapTest.ConflictingKey
either needs aSuppressWarnings
on it, or a flag passed to errorprone - I opted for-Xep:ComparableType:OFF
, as that seems to be the convention.At this point,
emul_tests_lib
can succeed in building.Next, I tried to build (not test) the modified
Lang
rule above - this failed with a confusing message:Is it accurate to say that suites don't work, but a single suite would? Regardless, I changed my custom rule to only run StringTest:
This passed a bazel build finally, but tests fail (specifically
testIndexOfNull
).Is there an easier way to go about running tests, so that we can migrate already-working java9-11 stream/optional/collection code into j2cl, complete with tests?
Would any/all of this be suitable for a contribution, so that a CI script could exist that runs these emulation tests, in anticipation of emulation patches?
gkdn commentedon Feb 1, 2024
The JRE unit tests are not ported to open-source so they would not work out of the box.
We are currently swamped with couple of a big projects but if you like to commit to the JRE emulation, the best I can offer at the moment is:
StringTest
injre/javatests/BUILD
with the class that you are testing.bazel test jre/javatests:StringTest
to run the testbazel run jre/javatests:StringTest_debug
and follow the link to run/debug on your browser.If you have further questions, let's start a discussion in the discussions section.
treblereel commentedon Feb 1, 2024
@gkdn Thanks a million; it works like a charm.
niloc132 commentedon Feb 2, 2024
Great, thank you @gkdn - different changes than I had made, but clearly solving the same issues. I appreciate the pointer to the
_debug
test target. @treblereel has submitted #222 with changes from GWT, verified in j2cl by running tests as you described.gkdn commentedon Dec 4, 2024
As of 1891f73, you don't need the patch to run JRE tests.
Added test target covers all supported platforms and cross tests with JVM for compatibility. Also includes instructions on how to debug.