Ok, I thought about this a bit, and the question is, “will this help with more and more dependencies being Java 11+” which is the primary driver for this?
> On Jan 7, 2023, at 12:54 PM, Tamás Cservenák <ta...@cservenak.net> wrote: > > Howdy, > > Maven daemon uses it, AFAIK Lucene as well. > https://github.com/apache/maven-mvnd/tree/master/daemon/src/main > <https://github.com/apache/maven-mvnd/tree/master/daemon/src/main> > https://github.com/apache/lucene/tree/main/lucene/core/src > <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 > <https://maven.apache.org/plugins/maven-compiler-plugin/multirelease.html> > > HTH > T > > On Sat, Jan 7, 2023, 19:30 <le...@flowlogix.com <mailto:le...@flowlogix.com>> > 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 <lhazlew...@apache.org >> <mailto:lhazlew...@apache.org>> 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 >> <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 >> <andr...@manticore-projects.com <mailto:andr...@manticore-projects.com>> >> 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 >
