<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Hi Arjan, <br>
</p>
<p>Java 8 is supported until 2030, and 17 to 2029, we would be
unable to continue testing against new Java releases. <br>
</p>
<p><a class="moz-txt-link-freetext" href="https://bugs.openjdk.java.net/browse/JDK-8272340">https://bugs.openjdk.java.net/browse/JDK-8272340</a></p>
<p>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. <br>
</p>
<p>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.<br>
</p>
<p>Regards,</p>
<p>Peter.<br>
</p>
<div class="moz-cite-prefix">On 2/05/2022 5:24 pm, arjan tijms
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAE=-AhCmn-f9L6Jh7Q8+EELM5tXHy5Ya6uTBM1_PvT+UzOD5Qg@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
Hi,<br>
<br>
On Monday, May 2, 2022, Peter Firmstone <<a
href="mailto:peter.firmstone@zeus.net.au" moz-do-not-send="true"
class="moz-txt-link-freetext">peter.firmstone@zeus.net.au</a>>
wrote:
<div><br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
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.</blockquote>
<div><br>
</div>
<div>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?</div>
<div><br>
</div>
<div>Kind regards,</div>
<div>Arjan Tijms</div>
<div><br>
</div>
<div><br>
</div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Regards,<br>
<br>
Peter.<br>
<br>
On 27/04/2022 3:38 am, Sean Mullan wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
On 4/26/22 1:06 PM, Scott Stark wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
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<wbr>(...) 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(<wbr>)
== 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.<br>
</blockquote>
<br>
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.<br>
<br>
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.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
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.<br>
</blockquote>
<br>
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.<br>
<br>
--Sean<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
Thanks,<br>
Scott<br>
<br>
On Apr 26, 2022 at 11:09:22 AM, Sean Mullan <<a
href="mailto:sean.mullan@oracle.com" target="_blank"
moz-do-not-send="true" class="moz-txt-link-freetext">sean.mullan@oracle.com</a>
<mailto:<a href="mailto:sean.mullan@oracle.com"
target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">sean.mullan@oracle.com</a><wbr>>>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
Hello Scott,<br>
<br>
On 4/25/22 2:25 PM, Scott Stark wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
Hello,<br>
<br>
I'm Scott Stark of Red Hat, and a member of the Jakarta
EE platform dev<br>
group (EEPD). I'm currently coordinating the Jakarta EE
10 release that<br>
is targeting June of this year (2022). The removal of
the<br>
SecurityManager as described in JEP-411 has been a topic
for the EEPD on<br>
may calls this year. Recent discussions make it clear
that any<br>
SecurityManager alternative would need to be taken up by
the EEPD, and<br>
such an effort is going to be a non-trivial undertaking,
and may not be<br>
addressed at all.<br>
<br>
A general concern among vendors in the EEPD is the
timeframe for the<br>
code that bridges between the JVM running with and
without a<br>
SecurityManager instance needing to be updated. Such
code is the subject<br>
of this JEP-411 paragraph:<br>
<br>
"In feature releases after Java 18, we will degrade
other Security<br>
Manager APIs so that they remain in place but with
limited or no<br>
functionality. For example, we may revise
AccessController::doPrivileged<br>
simply to run the given action, or revise
System::getSecurityManager<br>
always to return null. This will allow libraries that
support the<br>
Security Manager and were compiled against previous Java
releases to<br>
continue to work without change or even recompilation.
We expect to<br>
remove the APIs once the compatibility risk of doing so
declines to an<br>
acceptable level."<br>
<br>
Of particular interest is the timeframe for "remove the
APIs once the<br>
compatibility risk of doing so declines to an acceptable
level".<br>
<br>
Vendors in EEPD would like to see Java SE 21 ship with a
migration<br>
feature along the lines of the proposed
"AccessController::doPrivilege<wbr>d<br>
simply to run the given action, or revise
System::getSecurityManager<br>
always to return null" behaviors.<br>
</blockquote>
<br>
Can you clarify what you mean by "a migration feature" and
also provide<br>
some background as to why vendors in EEPD would like to
see this? Do you<br>
mean something like a system property that enables the
degraded behavior<br>
as described above?<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
Is there some metric for tracking "when the
compatibility risk of doing<br>
so declines to an acceptable level."? I believe the EEPD
vendors would<br>
like readiness of their projects and upstream
dependencies to somehow be<br>
included in any such tracking.<br>
</blockquote>
<br>
So, first we do not yet have a proposed target date for
when we would<br>
like to remove support for the Security Manager (SM) from
the JDK. By<br>
removing support, I mean that the JDK would no longer
include a SM<br>
implementation. However, I don't anticipate that any SM
specific APIs<br>
would be degraded *prior* to removing SM support from the
JDK.<br>
<br>
Some APIs will likely be degraded as described above at
the same time we<br>
remove support for the SM from the JDK.<br>
<br>
As for when the APIs will actually be removed, this will
most likely be<br>
a longer period, possibly several JDK releases. We
recognize that many<br>
libraries and applications will need time to adapt to the
changes and<br>
remove dependencies on the APIs. We have tools that check
open source<br>
repositories for API dependencies and are able to provide
us with data<br>
that helps assess the compatibility risk. However, I can't
give you a<br>
timeframe for API removal yet.<br>
<br>
HTH,<br>
Sean<br>
</blockquote>
</blockquote>
</blockquote>
<br>
</blockquote>
</blockquote>
<pre class="moz-signature" cols="72">
</pre>
</body>
</html>