would it be considerable to add Multi-Release JAR mechanism? virtual thread seems helpful in this repo.(at least helpful for bf)

[XenoAmess]

seems there be some thread executor in this repo be handling IO related things, looks like they should benifit from changing to virtual thread(loom) when using on newer jdk (19+)

New feature, improvement proposal

1. add something like

    <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-compiler-plugin</artifactId>
        <version>3.8.1</version> <!-- Use a version that supports multi-release -->
        <executions>
            <execution>
                <id>default-compile</id>
                <goals>
                    <goal>compile</goal>
                </goals>
                <configuration>
                    <release>8</release> <!-- Base version -->
                </configuration>
            </execution>
            <execution>
                <id>java9-compile</id>
                <goals>
                    <goal>compile</goal>
                </goals>
                <configuration>
                    <release>19</release>
                    <source>19</source>
                    <target>19</target>
                    <multiReleaseOutput>true</multiReleaseOutput>
                    <outputDirectory>${project.build.outputDirectory}/META-INF/versions/9</outputDirectory>
                    <includes>
                        <include>path/to/java19/specific/classes/**</include>
                    </includes>
                </configuration>
            </execution>
            <!-- Add more executions for other Java versions as needed -->
        </executions>
    </plugin>

    <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-jar-plugin</artifactId>
        <version>3.2.0</version>
        <configuration>
            <archive>
                <manifestEntries>
                    <Multi-Release>true</Multi-Release>
                </manifestEntries>
            </archive>
        </configuration>
    </plugin>

then modify the jdk19 version of that classes
then make ci use jdk21 to compile

[XenoAmess]

another way is write a spi mechanism in org.eclipse.aether.supplier.RepositorySystemSupplier#createDependencyCollectorDelegates
and start the jdk19 part in another package/jar, and then depend on it when needed...

means split out a bf19 collector...

[XenoAmess]

yet another way is force using jdk 21+ to build, then add some java version detect tools in the codes like if(javaversion >= 19) {...}

this is achievable though I don't think we should do it this way...

[Bukama]

@desruisseaux I think you can say something to this based on compiler

[desruisseaux]

With Maven 4.0.0-rc4 and Maven Compiler Plugin 4.0.0-beta, it can be done as below. The Maven compiler will take care of managing the classpath and putting the compiled classes in the right directories.

<build>
  <sources>
    <source>
      <targetVersion>17</targetVersion>
      <!-- defaut directory is src/main/java -->
    </source>
    <source>
      <targetVersion>21</targetVersion>
      <directory>src/main/java_21</directory>
    </source>
    <source>
      <scope>test</scope>
      <!-- default directory is src/test/java -->
    </source>
  </sources>
</build>

Even if IDE may not understand the above POM model yet, I think that they should work correctly if they use the Maven API. In my understanding, the NetBeans team is already working on upgrading NetBeans to Maven 4.

We have not yet released the Maven Compiler Plugin capable to do the above (the last released version is too old), but nothing block us from doing a release. The plugin is ready (except some last aspects of JPMS not relevant here), it is just a matter of taking the decision to release it.

[olamy]

looks like a nice feature. @cstamas wdyt?

[cstamas]

See #1541