All good thoughts. I suspect that now that 2.x is on Java 8 there are some clean ups we will want to do. What comes to mind immediately is deprecating our functional interfaces in favor of the ones in java.util.function. Then we can drop our custom functional interfaces in the 3.0 branch (if that did not already happen.)
At work, we are looking to move Java 11 as customers are uneasy running on an EOL version like Java 8 (I know, I know, commercial support). As far as making Java 11 the base requirement, we are somewhat waiting on IBM to make Java 11 available on z/OS (https://developer.ibm.com/javasdk/support/zos/) So overall my thoughts are to make use of Java 8 in 2.x and seeing how that allows 3.0 to be cleaned up. Gary On Sun, Dec 15, 2019 at 4:17 PM Ralph Goers <ralph.go...@dslextreme.com> wrote: > Now that 2.13.0 is pushed out I would like to focus again on 3.0. The > primary driver was to make it “compatible” with JPMS, i.e. properly define > each of the jars as a Java module. Some of our dependencies, like Jackson, > have implemented support so that we can now properly reference them, which > is one of the main reasons I believe things have been moving slow. > > Now that we have moved the 2.x releases to Java 8 I am wondering if we > shouldn’t make Java 11 the minimum for 3.0. It would simplify the build as > we would no longer need multiple Java versions installed, we would no > longer need toolchains, and we could simply move the code from the Java 9 > specific modules into their respective modules and clean up that code. It > would also make it much easier to implement a few other features that > require Java 9+. > > Obviously, if we have a minimum of Java 11 then we would need to continue > to support both the main and release-2.x branches for some time to come as > it is going to be quite a while before Java 8 falls out of favor. > > Thoughts? > > Ralph >
