Add Jigsaw module declaration

[sdeleuze]

The purpose of this issue is to add Jigsaw module-info.java with full exports and requires in order to allow creation of lightweight custom modular run-time image via jlink. Such image would be a good fit especially for Docker/Kubernetes based deployment.

See also https://github.com/reactor/reactor-netty/issues/180 and this tutorial.

[rasentry]

It is posible to add module-info.java using mixcompilation I use this config in my maven projects, It seems to me possible to do the same with gradle

<plugin>
   <groupId>org.apache.maven.plugins</groupId>
   <artifactId>maven-compiler-plugin</artifactId>
   <version>3.8.1</version>
   <executions>
      <execution>
         <id>default-compile</id>
         <configuration>
            <release>8</release>
            <excludes>
               <exclude>module-info.java</exclude>
            </excludes>
         </configuration>
      </execution>
      <execution>
         <id>module-compile</id>
         <goals>
            <goal>compile</goal>
         </goals>
         <configuration>
            <release>11</release>
            <includes>
               <include>module-info.java</include>
            </includes>
         </configuration>
      </execution>
   </executions>
   <configuration>
      <jdkToolchain>
         <version>11</version>
      </jdkToolchain>
      <release>8</release>
      <compilerArgs>
         <arg>-Xlint:unchecked</arg>
      </compilerArgs>
   </configuration>
</plugin>

So does it give a chance to implement modules earlier than in Backburner?

[kashike]

Is there any update on this? This would be really nice to have done.

[simonbasle]

@kashike there is currently no plan to tackle that in 2021, not while the baseline is Java 8. We might re-evaluate if there is a jump to Java 17 next year, and if the interest for this has increased enough to make the effort worth it.

[Sineaggi]

@simonbasle Has a jump to java 9 or 11 or 17 as a baseline been decided on? Is there any related ticked to follow?

[simonbasle]

@Sineaggi sorry for not getting back to you on that one earlier. End of January, the decision was made that the next version in 2022, reactor-core 3.5.0, will stay on a Java 8 baseline. So this is still out of scope.

[alexismanin]

Is there a roadmap somewhere that document future actions/timeline for java 17 migration and jigsaw migration ?

Does Spring framework 6 release affects project reactor decisions on the matter ?

Apart from Jigsaw modules, I am interested to know if (or when) reactor project will require Java 17 source compatibility. Is that planned already ?

[simonbasle]

As stated above, while we initially thought we'd take the Spring 6 release as an opportunity to bump our Java baseline as well, this was rolled back.

Reactor isn't Spring, and for a library as low level as it is, there still isn't much leeway in dropping Java 8 support.

I now don't expect that such a major change will even happen in the next few years, tbh.

[alexismanin]

It would be great to have just a document or an issue starting to list / plan efforts in this regard, even if it is greatly incomplete. Even if the task is postponed to reactor 4 in a few years ;-)

As closing thoughts, I will give my opinion about the required effort for migration. I see two separate tasks, which require very different amount of work :

• Setting Java 17 as minimal required version : It is a first step that would allow usage of Java features like records and sealed interfaces. As project-reactor is already "runtime compatible" with Java 17, it should not require a lot of actions.
• Modularization: This is, IMO, the biggest problem. Fine-tuned modularization might require a lot of manual work, and even possibly some API rework.

To expand my claim on modularization effort, I will take a simple example : the reactor Loggers utility class :

At this moment, it uses the java.util.logging package (like here). The problem is that java.util.logging package is not in java.base module, but in its own java.logging module (Cf. java.util.logging package apidoc).

Now, it requires a choice at library level :

• will reactor favors backward compatibility, and therefore define its core to require java.logging module ?
• Or is it best to rework logging utilities to avoid direct dependency to jdk logging, at the price of potential api break ?

Personally, I think the choice is not that easy to make !