Utilize VT if possible

[cstamas]

Also, lessen the pressure (creating eagerly as many threads as many CPU cores per archive is a huge pressure), as many times they are simply unused.

[cstamas]

Proof why "rebuild on each Java version" pattern is totally wrong: The CI. The JARs should be built on controlled Java + Maven version and then test performed on matrix, as right now, what you can use is really matrix minimum and that is outright silly.

[slawekjaranowski]

Proof why "rebuild on each Java version" pattern is totally wrong: The CI. The JARs should be built on controlled Java + Maven version and then test performed on matrix, as right now, what you can use is really matrix minimum and that is outright silly.

It is easier configuration ...

[cstamas]

Thanks!

Still, the reason I dislike this is that consumer may rightfully ask "and what Java was used to release this?" -- as we basically make a feature depend on Java version we use to release. The proposed solution (use one version to build and enforce it) makes the presence of feature clear, and not kinda optional-ish.

Also, if someone releases this library and by mistake use Java 17 or 11 (as library is Java 8+), nothing will happen: no big red alarm will ring, and the only way to figure out what happened is to inspect the release output Java...

[slachiewicz]

Or simply, faster switch to Java 21

[slawekjaranowski]

I added check in release profile to use 21+, so we will not have a mistake

[slawekjaranowski]

We can merge it ...
I will look at using many deprecated methods from commons-io .... and next release it