How to super-source with j2clmavenplugin?

[DragonAxe]

Super sourcing in Bazel, this looks like this according to the example here (https://github.com/google/j2cl/blob/master/docs/best-practices.md#super-sourcing-writing-platform-specific-code):

java_library(
  name = "logger",
  srcs = [ "Logger.java", ],
  deps = ":mydep",
)

j2cl_library(
  name = "logger-j2cl",
  srcs = [
    "super-j2cl/Logger.java", # swaperoo
  ],
  deps = ":mydep-j2cl",
)

How would this look with j2clmavenplugin?

My current plugin configuration looks like so:

    <pluginManagement>
      <plugins>

        <plugin>
          <groupId>com.vertispan.j2cl</groupId>
          <artifactId>j2cl-maven-plugin</artifactId>
          <version>${j2cl.maven.plugin.version}</version>
          <executions>
            <execution>
              <id>js-build</id>
              <goals>
                <goal>build</goal>
              </goals>
              <configuration>
                <compilationLevel>BUNDLE_JAR</compilationLevel>
                <enableSourcemaps>true</enableSourcemaps>
              </configuration>
            </execution>
            <execution>
              <id>test-js</id>
              <goals>
                <goal>test</goal>
              </goals>
              <configuration>
                <compilationLevel>BUNDLE_JAR</compilationLevel>
                <enableSourcemaps>false</enableSourcemaps>
                <webdriver>chrome</webdriver>
              </configuration>
            </execution>
          </executions>
        </plugin>

      </plugins>
    </pluginManagement>

[niloc132]

Broadly speaking: not supported in the same way. With that said, you didn't actually get to the important part in your example code - how do you write a single codebase that depends on Logger.java, then use it in both a Java application and a j2cl application?

The bazel answer is that you make two projects, one which depends on logger-j2cl, and one which depends on logger - they aren't the same project, they just happen to use the same sources.

Then, the j2cl application depends on the j2cl library, which depends on j2cl logger, and the java application depends on the java library, which depends on the java logger. There is no shared code at all, just shared source files that happen to be compiled twice, by parallel and totally unrelated/distinct projects.

You can do that in maven! But it won't really seem very maven-ish. That's your decision though - even in bazel if you had a moderately large codebase with several modules and hundreds of classes between them, maintaining two parallel dependencies trees might get irritating - or maybe not. I notice you aren't actually using bazel (as you're here in the j2cl maven plugin's discussion), so maybe the bazel way isn't so great either.

---

There is another way that works most of the time - since you already own both copies of Logger.java (as it is clearly in your sources, in the example), you can use the @GwtIncompatible annotation to let two implementations of a class behave like one. Copying/editing from the bazel doc you linked:

public class Logger {
  private static class JsImpl {
    public static void log(String s) {
      Console.log(getTime() + " " + s);
    }

    private String getTime() {
      return new Date().getTime() + "";
    }
  }
  private static class JreImpl extends JsImpl {
    @Override
    @GwtIncompatible
    public void log(String s) {
      System.out.println(getTime() + " " + s);
    }
    @GwtIncompatible
    private String getTime() {
      return System.currentTimeMillis() + "";
    }
  }

  public static void log(String s) {
    new JreImpl().log(s);
  }
}

The real method instantiates the JRE impl and calls it - you could also just keep a singleton depending on if you're holding state, etc. The JreImpl has decorated all of its members as being incompatible with j2cl/gwt, so j2cl pretends they aren't there, and relies on the members in the supertype. This way, the JRE gets to call its methods, and the JS env only calls code it is compatible with.

This isn't always perfect, as you might end up with trouble with further upstream dependencies - but the approach will save you (in both bazel and maven) from needing to duplicate the dependency hierarchy.

[DragonAxe]

Here's a quick sketch of my current project structure using a simplified example of two classes that depend on each other:

GradleRoot
┣━ GradleProjectA/src/main/java
┃  ┣━ ITimeable.java          (ITimeable interface has a method `tick(Timer)` which depends on Timer.java)
┃  ┗━ Timer.java              (Timer has a `List<ITimeable> targets` which depends on ITimeable.java)
┗━ J2clGradleWrapperProject
   ┣━ build/coppiedSources/GradleProjectA/src/main/java
   ┃  ┣━ ITimeable.java       (Translated by find/replace script; a caryover from when the project was using gwt.)
   ┃  ┗━ Timer.java           (ITimeable is excluded from copied sources because it is incompatible with j2cl.)
   ┗━ j2cl-maven-parent-project
      ┣━ maven-module-a
      ┃  ┣━ super/src/main/java
      ┃  ┃  ┗━ Timer.java     (J2cl compatible super-source)
      ┃  ┗━ pom.xml           (<sourceDirectory>../../build/copiedSources/GradleProjectA</sourceDirectory>)
      ┗━ pom.xml

How could I configure maven-module-a/pom.xml or rework this project structure so that super-source Timer and ITimeable can see each other at j2cl compile time?

I tried using the build-helper-maven-plugin to add additional source directories which works in the imidiate maven module, but j2clmavenplugin doesn't see build-helper-maven-plugin configured sources of dependencies.

maven-module-a/pom.xml:

  <build>
    <sourceDirectory>../../build/copiedSources/GradleProjectA</sourceDirectory>

    <plugins>

      <plugin>
        <groupId>org.codehaus.mojo</groupId>
        <artifactId>build-helper-maven-plugin</artifactId>
        <version>3.2.0</version>
        <executions>
          <execution>
            <id>add-additional-sources</id>
            <phase>generate-sources</phase>
            <goals>
              <goal>add-source</goal>
            </goals>
            <configuration>
              <sources>

                <source>super/main/java</source>
                
              </sources>
            </configuration>
          </execution>
        </executions>
      </plugin>
      
    </plugins>
  </build>

Let me know if you have any questions about this.

[niloc132]

This is a confusing project to me - it is a Gradle project (you can call j2cl from gradle - and gradle can do the programmatic project creation like bazel can...), but you're calling Maven from it... but not using maven conventions at all? That's a lot of layers, would you mind breaking it down to a plain Maven multi-module project, ideally one with just the 5ish source files plus 2-3 pom files, and possibly even upload that to github?

You can always reattach the Gradle wrapper wiring afterwards, but let's keep it to one build system at a time, and just focus on the supersource/gwtincompatible question with a minimum of distraction.

But at a glance, there is no code depending on Timer at all, maybe that was left out of the example? The concept of super-source doesn't work if there is no j2cl/gwt-compiled code which depends on it.

Alternatively, we can arrange for a screensharing call, and I can actively build/understand your project? Email me at colin@vertispan.com, we can arrange any NDA/invoice/contract you need to make this happen.

[DragonAxe]

super-source-example.zip

Sorry for the confusion. Hopefully this maven-only example project will clear things up. It will print out the following in Java and in a Browser:

Hello, World!
Hello: Example Timer 0
World: Example Timer 0
Hello: Example Timer 1
World: Example Timer 1

The project has 4 sub-maven-modules:

common                (A set of common library classes)
common-j2cl           (Contains j2cl super-sources for `common`,
                       except it contains a duplicate Timeable interface to make things compile which isn't ideal)
example-project       (Java only main class, uses common library)
example-project-j2cl  (J2cl only main module, uses common-j2cl library)

The goal for this example project would be to eliminate one of the duplicate Timeable interfaces using super sourcing.

[DragonAxe]

The Timeable, Timer example is very simplified from the original project.
It just occurred to me that I could make Timer an interface, put the Timable and Timer interfaces in the common project, and implement Timer in the Java/J2cl projects respectively. I'm not sure if that's feasible with the rest of the classes I'm working with, so it would still be nice to have a super-sourcing option.

P.S. I keep spelling "super-sourcing" like "souper-sourcing" ( 🍜 - sourcing )

[niloc132]

Glad you've got a pattern that seems to work - I generally prefer approaches that feel more like "regular Java" rather than things like super source that can be perceived to be "magic" by other team members who aren't digging in as deeply.