On Tue, Feb 27, 2024 at 8:27 AM Piotr P. Karwasz <piotr.karw...@gmail.com> wrote: e will not be loaded even if it is available. > > Fortunately Commons Compress is well-engineered and easy to split. The > code that depends on: > > * com.github.luben:zstd-jni, > * org.brotli:dec, > * org.ow2.asm:asm, > * org.tukaani:xz. > > is already nicely separated in packages. IMHO those packages could be > moved to separate artifacts **without** requiring a major version bump
I wish. It's not that commons-compress is badly factored. It's that Maven and Java don't really allow for compatible upgrades that split existing artifacts into new artifacts. This causes big, hard-to-debug runtime failures. The problem is bad in Java 8 and earlier. It got much worse in Java 9+ with JPMS. The only compatible path that splits artifacts is to rename both the Maven coordinates AND the packages. Otherwise there will be multiple copies of the same class in the classpath, and either the wrong one will be chosen some of the time causing hard to debug runtime failures or (with JPMS) the JVM will simply refuse to run the program at all. What you describe is a good greenfield plan, but it's not a compatible upgrade, not even with a major version update. -- Elliotte Rusty Harold elh...@ibiblio.org --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
