JRE emul and java 11 jpms issue

[treblereel]

Note: I’m not going to discuss the module-info.java issue here.

To start, let's refresh our memory on the processing stages for a Maven module:

• BytecodeTask unpacks classes, and if it's a Maven reactor module, then it compiles them while executing annotation processors. Technically, Turbine can be used to run annotation processors.
• StripSourcesTask removes parts of the code that have the @GwtIncompatible annotation.
• TurbineTask generates method signatures from the source code.
• J2clTask compiles Java into Closure annotated JavaScript; actually, JRE emulation sources are only needed at this stage.

It's important to clarify that BytecodeTask works differently for external dependencies and Maven reactor projects. In the case of an external dependency, the contents of the jar are unpacked into the gwt3BuildCache as is. However, it is compiled if the dependency is a Maven reactor module. This is necessary to enable the inclusion of annotation processors within the Maven reactor module. However, this becomes a blocker when the Maven reactor module contains JRE emulation classes, such as java.text.Format. In this case, we receive an Exception: package exists in another module: java.base. Again, if java.text.Format is located in a jar, this error does not occur, and the build is successfully completed.

Several solutions to this problem can be proposed:

• Repackage the JRE emulation with the addition of JRE emulation classes such as java.text.Format. This seems like a resource-intensive task, as it would require recompiling the JRE emulation bundle every time such a module changes.
• Exclude java.* javax.* classes from compilation. This seems to be too radical a solution.
• Do as GWT does (super-source) and use marker files containing the path to the directory we want to use but don't want to compile. There could be many options, such as a module descriptor in META-INF.
• Use the recommendations from the J2CL team and agree to store such classes in super-J2CL folders (J2CL Best Practices).

The last two options seem to me the most advantageous.

Do you have any ideas? Could I have missed something?

[treblereel]

• we can exclude from compilations packages starting from java, javax and so on :)

or scan those packages (for classes) recursively into trie, just to ban those classes