On Sat, May 24, 2025 at 6:22 PM Martin Desruisseaux <martin.desruisse...@geomatys.com> wrote:
> Java 9+ for supporting JPMS. This is needed not only in some plugins > (compiler, javadoc, maybe surefire), but also in some places of Maven > core (class-path versus module-path, cache of module-info). Even if not > everyone is interested in JPMS, trying to enable JPMS while preserving > Java 8 compatibility (e.g. with reflection) would have been difficult. Can you be more specific? Is there some code we need to produce or compile that we cannot compile with Java 8? We are still trying to figure out how to lay out code for multi-module projects. That we haven't yet figured this out and haven't really needed to. suggests that maybe multi-module projects aren't all that important in the real world. JPMS has pretty much failed. It's not clear it was ever needed in the first place. That said, I would like to be able to support multi-module builds, but what exactly can't we do without requiring Java 11? There's plenty of Java 8 code that is fully compatible with JPMS. There's also some that isn't, typically due to split packages. However, those problems aren't resolved by upgrading the JDK. In fact, that's a reason a lot of projects avoid JPMS completely. All that said, if you can demonstrate in detail that Java 11 is required for Maven to build projects that use JPMS, and we have a plan for addressing everything else needed to support multi-module builds, then I would find that a compelling reason to require Java 11. It isn't easy though. I took a run at this myself during quarantine and got nowhere. > Java 16+ for starting the migration to records. Some data structures in > Maven core overlap with Java records. In particular, all the classes > generated from the `maven.mdo` file, but not only. In short term, > migrating to records would remove the need to declare constructors, > hashCode and equals methods, thus making classes simpler and reducing > the risk of bugs. In medium term, "derived record creation" (currently > in preview) could replace builders. That would be a massive > simplification of record-like classes. As much as I would like to rip out Modello and chuck it into the Mariana trench, I don't think that's likely to happen. Consequently this is a non-starter. If you do manage to rip out and replace Modello, then we can talk about record classes, but I don't want to have both Modello and record classes, which is what would likely happen if we tried this today. > Java 24+ (in a later Maven version) for class-file API. It would resolve > at least some of the compatibility problems observed when new Java > versions are released and Maven wants to analyse the byte code. This one is interesting. Unfortunately it's far too early to require Java 24+ for users, which is what we'd need for this, since users would need to run code that calls this API. I don't want to predict exactly when this will be possible. However, it's multiple years away. Most big dev shops are extremely slow to upgrade. 3 years ago when I left Google, they had just finished a multi-year company wide migration to Java 11. Meta isn't as big a Java shop, but they too were using Java 11 at least through late 2024. They and others will eventually get to Java 25, but that's years in the future. -- Elliotte Rusty Harold elh...@ibiblio.org --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
