Interesting.
I wonder about the "rarely used to secure server-side code" point.
Rarely, yes in terms of the overall server-side java universe. But I
suspect in some significant contexts, e.g. government, it's not so rare.
On Thu, Apr 15, 2021 at 2:43 PM Richard Opalka <ropalka(a)redhat.com> wrote:
FYI
---------- Forwarded message ---------
From: <mark.reinhold(a)oracle.com>
Date: Thu, Apr 15, 2021 at 8:06 PM
Subject: New candidate JEP: 411: Deprecate the Security Manager for Removal
To: <sean.mullan(a)oracle.com>
Cc: <security-dev(a)openjdk.java.net>, <jdk-dev(a)openjdk.java.net>
https://openjdk.java.net/jeps/411
Summary: Deprecate the Security Manager for removal in a future
release. The Security Manager dates from Java 1.0. It has not been the
primary means of securing client-side Java code for many years, and it
has rarely been used to secure server-side code. To move Java forward,
we intend to deprecate the Security Manager for removal in concert with
the legacy Applet API (JEP 398).
- Mark
--
Richard Opalka
Principal Software Engineer
Red Hat JBoss Middleware
Mobile: +420 731 186 942
E-mail: ropalka(a)redhat.com
_______________________________________________
wildfly-dev mailing list -- wildfly-dev(a)lists.jboss.org
To unsubscribe send an email to wildfly-dev-leave(a)lists.jboss.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s