User-agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.9.1
I 100% agree with your position on the warnings. Perhaps
requesting some control over this noise might be worth a comment,
in the JEP.
If we have use-cases specific to EE, we should consider how we'd
like to address those as well. We can do that in a number of ways.
I suspect, the first thing, will be to enumerate where the EE
specifications specifically call this out and decide how we would
like to address these use-cases.
Getting back to the JEP, I am sure the JDK team would like to
hear if there are specific use-cases that should be preserved
and/or re-written especially those that might be universal to Java
programs. Again, obtaining that feedback is exactly what the JEP
process is designed to solicit.
-- Ed
On 4/15/2021 4:30 PM, arjan tijms
wrote:
Hi,
Indeed, this won't be anytime soon. Still, it's like all
those warnings about illegal reflection that we've been
ignoring for years. At some point though you can't longer
ignore them and have to address the issue.
p.s. this thread from 2014 goes into some of the details
why the Security Manager was never an optimal fit for server
side code anyway:
The JEP only indicates that these APIs will begin the
deprecation process. Yes, we will need to address this,
but the functionality won't actually be removed, at the
earliest, before the next following LTS release (probably
in the 20's).
If anyone has feedback, feel free to provide it via the
JEP -- that is explicitly what this kind of notification
process is designed to solicit.
"Jakarta EE has several requirements on the
Security Manager. These must be either relaxed or
removed in order for compliant applications to run
on future Java releases after the Security Manager
is degraded and then removed."
Now I've personally been arguing for not
using/depending on the security manager in server
side code for a long time. The idea of running
potentially untrusted code on your own server
always struck me as awkward and something you
would not do anyway, even when running multiple
applications on a single server instance was still
somewhat of a thing.
The TCK and GlassFish use the security manager
a lot, so that would have to be removed depending
on the final outcome of JEP 411.