Hi Arjan,
Java 8 is supported until 2030, and 17 to 2029, we would be unable to
continue testing against new Java releases.
https://bugs.openjdk.java.net/browse/JDK-8272340
With this choice, there will be incompatible Java versions we must
prevent our software from running on, until it becomes possible to
support a later version.
It also means that someone who wants to use new Java API's on a Java
version we don't support may be forced to migrate away from using our
software. It also means that we will be unable to take advantage of
new Java API's which may put us at a significant disadvantage.
Regards,
Peter.
On 2/05/2022 5:24 pm, arjan tijms wrote:
Hi,
On Monday, May 2, 2022, Peter Firmstone <peter.firmst...@zeus.net.au>
wrote:
I guess I'm just trying to say we need more time, the process of
extricating SM for security will take years, if we can leave SM as
it is in deprecated form for a number of years, that would be
greatly appreciated.
Just wondering, but would it not be an option to just keep using the
last LTS that has the SM? That may well enable you to keep using the
SM for something like 10 years?
Kind regards,
Arjan Tijms
Regards,
Peter.
On 27/04/2022 3:38 am, Sean Mullan wrote:
On 4/26/22 1:06 PM, Scott Stark wrote:
By "migration feature" I'm talking about being able to
retain the type of library code where one has a
conditional call to an AccessController::doPrivileged(...)
method that is only done when System.getSecurityManager()
is not null. Not having to remove this code in all
dependent libraries for a given Jakarta EE application
server product in order to run on Java SE 21 is seen as
necessary to navigate supporting application servers over
a range of Java SE versions. The general consensus was
that having to deal with Java SE 11, 17 and 21 would only
be possible if this SecurityManager related code could
remain as is, even if the only executed path would be
for System.getSecurityManager() == null. We can deal with
a gradual degradation of the SecurityManager behavior, but
it was unclear if Java SE 21 was looking for a complete
removal of the APIs the libraries use.
Yes, we understand these concerns. We recognize the
compatibility issues and the importance for code using the SM
APIs to continue to work as if an SM has not been enabled.
This is the motivation behind the language in the JEP that
discusses a gradual degradation and phasing out of the SM APIs
until the compatibility risk is low enough that removal is
acceptable.
Also, you mention SE 21, but as of yet there is not yet a
targeted release for the SM removal. There will likely be a
JEP for the removal of the SM and this will need to go through
several phases of the JEP process before it can be targeted to
a specific release.
I'm sure many of the Jakarta EE platform dev members have
code repositories to offer for scanning to aide in
determining when the SecurityManager dependencies have
been removed. If there is a avenue for that information,
please let me know.
Thanks for that offer. I don't have an avenue for that
information yet, but I will see if we can start creating a
list of significant SM-enabled libraries and other projects
that we can monitor over time.
--Sean
Thanks,
Scott
On Apr 26, 2022 at 11:09:22 AM, Sean Mullan
<sean.mul...@oracle.com <mailto:sean.mul...@oracle.com>>
wrote:
Hello Scott,
On 4/25/22 2:25 PM, Scott Stark wrote:
Hello,
I'm Scott Stark of Red Hat, and a member of the
Jakarta EE platform dev
group (EEPD). I'm currently coordinating the
Jakarta EE 10 release that
is targeting June of this year (2022). The removal
of the
SecurityManager as described in JEP-411 has been a
topic for the EEPD on
may calls this year. Recent discussions make it
clear that any
SecurityManager alternative would need to be taken
up by the EEPD, and
such an effort is going to be a non-trivial
undertaking, and may not be
addressed at all.
A general concern among vendors in the EEPD is the
timeframe for the
code that bridges between the JVM running with and
without a
SecurityManager instance needing to be updated.
Such code is the subject
of this JEP-411 paragraph:
"In feature releases after Java 18, we will
degrade other Security
Manager APIs so that they remain in place but with
limited or no
functionality. For example, we may revise
AccessController::doPrivileged
simply to run the given action, or revise
System::getSecurityManager
always to return null. This will allow libraries
that support the
Security Manager and were compiled against
previous Java releases to
continue to work without change or even
recompilation. We expect to
remove the APIs once the compatibility risk of
doing so declines to an
acceptable level."
Of particular interest is the timeframe for
"remove the APIs once the
compatibility risk of doing so declines to an
acceptable level".
Vendors in EEPD would like to see Java SE 21 ship
with a migration
feature along the lines of the proposed
"AccessController::doPrivileged
simply to run the given action, or revise
System::getSecurityManager
always to return null" behaviors.
Can you clarify what you mean by "a migration feature"
and also provide
some background as to why vendors in EEPD would like
to see this? Do you
mean something like a system property that enables the
degraded behavior
as described above?
Is there some metric for tracking "when the
compatibility risk of doing
so declines to an acceptable level."? I believe
the EEPD vendors would
like readiness of their projects and upstream
dependencies to somehow be
included in any such tracking.
So, first we do not yet have a proposed target date
for when we would
like to remove support for the Security Manager (SM)
from the JDK. By
removing support, I mean that the JDK would no longer
include a SM
implementation. However, I don't anticipate that any
SM specific APIs
would be degraded *prior* to removing SM support from
the JDK.
Some APIs will likely be degraded as described above
at the same time we
remove support for the SM from the JDK.
As for when the APIs will actually be removed, this
will most likely be
a longer period, possibly several JDK releases. We
recognize that many
libraries and applications will need time to adapt to
the changes and
remove dependencies on the APIs. We have tools that
check open source
repositories for API dependencies and are able to
provide us with data
that helps assess the compatibility risk. However, I
can't give you a
timeframe for API removal yet.
HTH,
Sean
