> On May 8, 2021, at 5:14 AM, Gilles Sadowski <gillese...@gmail.com> wrote: > > Hello. > > Le sam. 8 mai 2021 à 08:42, Benjamin Marwell <bmarw...@apache.org > <mailto:bmarw...@apache.org>> a écrit : >> >> Instead of using byte buddy, why not just maven multi release jars? *1 > > Thanks for the suggestion. > Again, I don't know how to do it concretely[1] nor the implications > (IIRC, the mention of multi-release JARs was frowned upon some > time ago).
Log4j 2 2.x has used multi-release jars for a few years. All the real issues have long been solved. The remaining complications probably won’t be an issue for Commons. The main issue is that some classes and/or methods were eliminated in Java 9 with new replacements added. This was a poor decision by the OpenJDK team/Oracle as it means that if you want to support both Java 8 and 11 and you use classes only available in Java 8 that you must have multiple compile steps in the build of your module and use toolchains to control which JDK gets used. If you don’t have dependencies on classes or methods that are no longer available then using the Java 11 compiler should work fine. > >> The Java9+ impl will go to META-INF/java9 or so. We did that in the >> maven-jlink-plugin for example. *2 >> Will be much faster and work on Java 16+. Much easier to rest. > > All good points, I guess. > > However, what about the potential of having a user-selectable > version of the implementations of the functions contained in > the JDK's "Math" class? Why? You should know how the JDK is going to behave. You can create classes that wrap JDK stuff where Java’s Math works well and have the wrapper call something else when it does not. You don’t need any logic to do that. You just provide a wrapper at the appropriate release levels and Java will take care of loading the correct one. Ralph
