Require Java 17 to use this library

[rfscholte]

Since Java 8 the language has been improved a lot.
Keeping this library on Java 8 means being blocked to use new features.
Projects that for some reason need to stay on Java 8 should lock plexus-archiver to version 4.12.0

[slawekjaranowski]

As project depends also on others components like commons-io, commons-compress, zstd-jni, xz
and project is used eg in many Maven plugins in version 3.x - JDK 8
https://github.com/search?q=%22%3CartifactId%3Eplexus-archiver%3C%2FartifactId%3E%22+language%3A%22Maven+POM%22++NOT+is%3Aarchived+org%3Aapache&type=code

I hope you have an idea for maintaining also 4.x with dependencies updates especially with security issues,
and you will prepare code and infrastructure, like GitHub actions, release-drafter, documentation for both branches ....

I hope that cost of maintenance two branches is reasonable with new features of JDK 17+ even I don't see such reason now.

By the way I think we should discuss such changes ....
@rfscholte, @slachiewicz @hboutemy

[rfscholte]

I understand the concern about the existing Java 8 users of plexus-archiver, especially given how widely the library is used by Maven plugins.

However, I don't intend to maintain two equivalent development branches of plexus-archiver. My proposal is to make the major version change precisely because the existing Java 8 compatibility should no longer constrain the development of the library.

The Java 8 requirement made sense when Java 8 was still a dominant runtime in the ecosystem. That situation has changed significantly. The overwhelming majority of projects using plexus-archiver are already running on a recent Java version, while the remaining Java 8 users are increasingly an exception rather than a reason to keep the library constrained to Java 8.

There is also an important distinction between the Java version used to run Maven and the Java version targeted by a project being built by Maven. Maven Toolchains already provides a mechanism for building projects for a different JDK version from the JDK used to run Maven itself. Therefore, Maven plugins being able to run on Java 8 should not necessarily mean that every library used by those plugins must remain Java 8 compatible.

I would therefore see the versions as follows:

• 4.12.0 remains the existing Java 8-compatible release.
• 5.x moves to a modern Java baseline and becomes the actively developed version.
• I am proposing not to maintain 4.12.0 and 5.x as two actively developed branches.

Projects that still need Java 8 can continue using 4.12.0. Consumers that support newer Java versions can migrate to 5.x. Consumers that need to support both environments could also make the dependency selection conditional on the Java version, for example through a Maven profile. This provides a migration path without requiring plexus-archiver itself to maintain two development branches.

I also think it would be useful to distinguish the maintainers of Maven plugins from the end users of plexus-archiver. The fact that a number of Maven plugins currently use plexus-archiver 4.x does not necessarily mean that their users require plexus-archiver itself to remain Java 8 compatible. In some cases the constraint may simply be inherited from the Maven plugin's own runtime baseline.

For that reason, I am very open to starting a discussion with actual end users of plexus-archiver. I would be happy to look at concrete cases where moving to 5.x would cause problems and see whether we can help those users move forward. There is even a possibility that we are currently focusing on a problem that is much smaller in practice than the dependency graph suggests.

I would prefer to validate that with the users rather than assume that every existing Java 8 consumer needs a permanently maintained Java 8 branch.

There is also a broader security consideration here. Projects that continue to run on Java 8 already have a Java runtime support and security consideration of their own. Keeping plexus-archiver on Java 8 does not resolve that underlying issue. I therefore don't think that dependency security should by itself be a reason to prevent the library from moving to a modern Java baseline.

The goal of 5.x is not to abandon existing users. It is to allow plexus-archiver to move forward without Java 8 remaining a permanent constraint, while giving existing users a concrete and manageable migration path.

[slachiewicz]

Who exactly will maintain 4.x version in pararel to 5.x to offer security fixes to 4.x? Becouse above LLM response doesn't covert that

[rfscholte]

We should only be talking about CVE's, and like always the first step is to upgrade to the latest and greatest, which would indeed be a 5.x. If there are still projects that only execute with a Java8 runtime, I would really want to get in touch with them. (Apache Maven does not only execute on Java 8, but also on the most recent Java versions)

If you still think that this library should be pro-active on this topic (Even though there's no evidence that end users need it), I can turn this project into a multirelease jar. The newly added code benefits a lot from sealed classes.