Documentation/example on adding JRE support to a project?

[niloc132]

Previous discussion: #157 (comment)

In that comment, the very reasonable point is made that adding arbitrary JRE classes/members to j2cl may not make sense for everyone - indeed, Dmitrii and I have different "gwt-nio" projects with different aims (one seeks complete emulation, the other seeks to limit itself to what can be efficiently done in the browser).

We're in the process of providing a flatbuffers implementation for GWT, and hoping to also make it J2CL compatible, and have been trying to use closure-compiler and guava as a guide here. However, both of those use only the stock JRE classes that can be found in j2cl (naturally, being Google projects), while FlatBuffers requires java.nio.ByteBuffer.

It is fairly straightforward when using Java 8 to just add java.* classes to a project, but with Java 11 and Bazel, I don't see any examples or documentation showing how this might be done. Is this the kind of thing that is intended to be supported but isn't? I would rule out forking j2cl itself and adding support directly with no hope of upstreaming it.

We've explored a few options to build this ourselves, but before picking an approach that works for Maven and might not work for Bazel, I was hoping to see if there was an "official" answer, or if we should just target our FlatBuffers implementation as "GWT and j2cl+maven only".

[gkdn]

Like you pointed, with Java 11 providing JRE emulation externally got more problematic. The main problem is mainly around adding new classes to existing modules.
However in this particular case since java.nio is not claimed by J2CL's JRE, I expect it to be pretty straightforward. There is actually a java.nio implementation internally used by a particular project (and again like you pointed something that works for their use case). The definition is a regular j2cl_library target where other targets add a dependency to.

Is that not working? If not, maybe something is different in Bazel that might be causing a problem...

[gkdn]

Yes currently I only know a solution for making additional JRE that is not sharing a package. Anything beyond that we'll need to check with Bazel Java folks to see if there is a workaround that we haven't tried before.

[niloc132]

Spitballing:
What would you think of a bazel project structure that does its best (i.e. allowing for cycles) to provide a BUILD file and j2cl_library() for each java.* package, so that they can be selectively replaced?

Especially in light of #240, it might make sense anyway to split the jre.js file (with its goog.provide() calls) into it own j2cl_library() anyway, so that it can have a distinct closure_js_library()-generated .i.js file?

[gkdn]

The situation around default JRE is more hairy; base JRE is not simply a j2cl_library; we need to create a bootclasspath and jdk system to compile. Also I don't think JDK is separable per package due to cycles; I believe that's one of the reasons it took quite bit of work to end up in current JDK module system. We would probably end up needing a set of sources for something to work instead of "libraries".
Also even with all of that, I'm not sure around the idea of having everything replaceable in JRE; sure will hit us back down the road :)

[treblereel]

@gkdn @niloc132 I use a tweaked version of j2cl-m-p that is able to exclude .java from compilation to bytecode (useful in case of maven reactor project has a module with such classes like nio) so I can use nio with java11.
So, in fact, I feed j2cl transpiler only with nio sources. My maven nio artifact contains only java classes and I never compiler them to the bytecode.

my setup:
https://github.com/treblereel/j2cl/tree/v20240622-1
https://github.com/treblereel/j2clmavenplugin/tree/v20240622-1_java11
https://github.com/treblereel/gwt-nio/tree/development

Did I miss any pitfalls?

[gkdn]

I don't exactly understand how you setup and maven works but if you supply same Java sources to multiple different J2CL transpilations, when you bundle them together at the end you will have problems.