You are not unique in that respect :) we'll have so support Java 8 for
some years as well.
But java 8 / security manager removal are not necessarily the same thing
- we can continue to base our code on Java 8 - just not support the
security manager anymore. Not sure if that is an option for you?
I totally agree that we should avoid branches, that creates too much
work without a real benefit.
Regards
Carsten
On 24.07.2024 14:47, Thomas Watson wrote:
I may be in a unique position of having to support Java 8 until
around October 2026. I suspect they will only make the methods no-ops
(return null for getSecurityManager, do nothing on doPrivileged etc.) until
the extended support of Java 8 expires in 2030. I would not aggressively
remove the optional usage of the security manager unless you have other
needs to bump the minimum required execution environment of the bundle.
For the few Felix bundles I am involved with I do not plan to update their
minimum execution environment for the main development branches beyond Java
8 for the time being. If the community wants to be more aggressive there
then I will have to resort to a branch to maintain the previous version of
the bundle to continue supporting Java 8. For things like SCR I will not
look forward to having to double deliver fixes though ...
Tom
On Wed, Jul 24, 2024 at 7:14 AM Carsten Ziegeler <cziege...@apache.org>
wrote:
Hi,
java security manager has been deprecated with Java 17 and is in the "to
be removed" list (see [1])
We have (optional) usage of the security manager all over the place in
our code base.
I'm wondering if it is time to remove that code now or do we wait until
it actually gets removed? Or...?
[1]
https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/lang/System.html#getSecurityManager()
Regards
Carsten
--
Carsten Ziegeler
Adobe
cziege...@apache.org
--
Carsten Ziegeler
Adobe
cziege...@apache.org
