Thank you for your input Emond!
Unfortunately I don’t think our small volunteer team can handle two major
versions that are in sync.
Anyone else think differently?
> On Mar 15, 2024, at 5:42 AM, Emond Papegaaij <[email protected]>
> wrote:
>
> Op vr 15 mrt 2024 om 05:10 schreef <[email protected]
> <mailto:[email protected]>>:
> 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
>
