Op vr 15 mrt 2024 om 05:10 schreef <le...@flowlogix.com>: > Since Shiro 2.0-alpha and 2.0 Final has been released, most, if not all > questions we have been getting are about Jakarta EE integration. > Mostly regarding shaded artifacts and their usage, i.e. jakarta.* > namespace. > These and other discussion warrant a few question worth discussing. > Please keep in mind by the time Shiro 3.x is released, it could be 2025 or > later. > > 1) How long should Shiro 1.x be maintained? > Not at all? 6 months? 1 year? 2 years? Other? > Upgrading to 2.0 isn't that hard, but it could be that you depend on a third party library that uses shiro, making it impossible to upgrade until this third party library has been upgraded. I would therefore say: support 1.x for 1 or 2 more years, but security fixes only. This should keep the efforts of maintaining that version to a minimum.
> 2) Should Shiro 3 support javax.* namespace via shading at all? > Not at all (drop support?) As shaded artifact? As different version > (shiro-core:3.0-javax)? > I would propose a slightly different solution here: move Shiro 3 to Jakarta (and maybe SE 17), but keep it identical to 2.x on all other aspects. You can then also drop the transformed artifacts with the jakarta classifier on 2.x. This will require back (or forward) porting of all changes, and performing releases in tandem, so it does impose some maintenance overhead. However, given the fact that the code is identical (with the exception of name spaces, mostly in imports and poms), the overhead should not be that big. > 3) Should Shiro 3 support SpringBoot 2.x or drop support for SB 2.x at all > (requires dropping support for javax namespace) > With the solution provided above, the answer to this question would be 'no'. Shiro 3 is for the Jakarta namespace. 4) What’s the minimum Java version? > Keep it at 11? Switch to 17 (both SpringBoot 3.x and Jakarta EE 11 require > 17+)? Switch to 17? Switch to 21 as minimum version? > Personally, I don't really care about the Java Shiro uses for development. The most important thing is that Shiro runs without issues on modern SEs. So, if you keep the development at SE 11, make sure you run your tests on at least 17 and 21 as well. For Wicket, we even run our tests on the latest early access releases. This helps us find issues early on. Switching source level to 17 will make your life easier, but it shouldn't make much difference for most users (except when you are still on SE 11, but in that case, you can use 1.x). I think it is too early to require 21, but many servers and platforms already require (or recommend) 17, so switching to 17 does make sense. To give a bit more insights into the landscape at our company: We've got quite a few applications. All of then run on SE17. We are migrating from JEE8 to JEE10. Some of the applications finished this migration last year, but for some of the larger applications (about 1.5M lines of code per such application) this is not an easy task. Especially, the migration from Hibernate 5 to 6 is hard. We hope to finish the migration to JEE10 for all but one of our applications this year. IMHO if you are behind as a company in maintaining your source code and still depend on old technology, you should either pay for this support, perform the required maintenance on these components yourself or migrate to newer, supported versions. Best regards, Emond
