Howdy, Maven daemon uses it, AFAIK Lucene as well. https://github.com/apache/maven-mvnd/tree/master/daemon/src/main https://github.com/apache/lucene/tree/main/lucene/core/src
Also, for maven, you have nice doco https://maven.apache.org/plugins/maven-compiler-plugin/multirelease.html HTH T On Sat, Jan 7, 2023, 19:30 <[email protected]> wrote: > Interesting… I have never used multi-releas JARs > Do you, by chance, have an example of any Maven-Java-based OSS projects > using it so I could take a look as an example? > Nice to hear from “the creator” BTW! > > On Jan 7, 2023, at 12:21 PM, Les Hazlewood <[email protected]> wrote: > > Saw this and thought I'd chime in - something to think about for the Shiro > dev team: > > Given the velocity of JDK feature releases, it's harder and harder to have > a 'baseline' JDK for most open-source libraries, including Shiro. The > (IMO) insane departure of the Java team from Semantic Versioning JDK > versions is utterly stupid as it further destroys trust in the > compatibility ecosystem. But I digress :) ... > > The best solution for feature divergence in APIs that I have been able to > find (IMO) is the concept of multi-release jars, supported in Java 9 and > later. You can program the base for JDK 8, and then additional > later-version features or API usage can be added for respective JDK > versions, all in the same jar: > > https://www.baeldung.com/java-multi-release-jar > > This allows users to automatically have the API-compatible features they > want for the JDK version they use, without any special concerns for which > Shiro jars they need to depend on. > > It's not a silver bullet, but with the proper use of Interfaces and > occasional direct class overwriting per multi-release jar semantics, you > can solve most, if not all of the API compatibility concerns. > > Just my .02. ;) Cheers! > > Les > > On Sat, Jan 7, 2023 at 12:14 AM Andreas Reichel < > [email protected]> wrote: > >> Bonjour mon ami! >> >> On Sat, 2023-01-07 at 08:59 +0100, Francois Papon wrote: >> >> Just a note, we will try to maintain the branches 1.x / 2.x when moving >> on 3.x for main. >> >> All good then. >> >> My very personal opinion and experience: >> >> - Java 11 LTS has been released on September 2018 >> >> - Java 17 LTS has been released on September 2021 >> >> - Java 21 next LTS is plan to be release on September 2023 >> >> In the "developed" markets, this migration schedule may happen with 2 >> years of a delay. >> However, in the "emerging" markets you can easily add another 5 years >> since they tend to maintain infrastructure only when the hardware breaks >> down. I do see Centos 6 Linux with Java 8 running in large banks here. And >> I have to maintain software on those 😞 >> >> Of course, they also will be less interested in back-ported security >> fixes ("Log4J" did not happen here.) >> So as long as any version of Shiro 1 will be available in any repository, >> we should be good. >> >> Cheers! >> Andreas >> > >
