Hi, my +1 for this proposal. Breaking changes (new Java baseline) requires a new version. Romain pointed out that MRJars, as Les suggested, have undefined behaviour in web apps. We also found only few use cases in most apps. Let's keep them in mind for when we *really* need them, shall we?
For Shiro 3.x, we could go to Java 21 if that's (long) out by then. Big +1 on the Jakarta specs :) Ben Am Sa., 7. Jan. 2023 um 05:03 Uhr schrieb <le...@flowlogix.com>: > > Hi, > > I am proposing the following support matrix for Shiro: > > Current (Shiro 1.x): Java 8, Jakarta 8-10+ ( 9+ via shade / classifier) > Future (Shiro 2.x): Java 11, Jakarta 8-10+ ( 9+ via shade / classifier), > full JPMS module support > Future (Shiro 3.x): Java 17, Jakarta 9-10+ ( source code uses jakarta.* > packages directly), full JPMS module support > > This is due to the fact that more and more of Shiro’s dependencies are > requiring at least Java 11, so if we are unable to upgrade those, it’s > becoming > more and more of an issue for the future development and support of Shiro, > never mind security concerns due to out-of-date dependencies. > > Any feedback appreciated. > > Thank you!
