RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal [v3]

[Phil Race]

On Wed, 19 May 2021 22:14:20 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> I don't think it is a separate P4 enhancement (?) that someone will (maybe) do next release.
>> I think it should all be taken care of as part of this proposed change.
>
> I just made it P3 (P4 was the default value), and I will target it to 17 once JEP 411 is targeted 17. But I think it's probably not a good idea to include it inside *this* PR. There are some middle ground where it's debatable if a change is worth doing (Ex: which is uglier between an a-liitle-faraway-annotation and a temporary variable?) so it's not obvious what the scope of the refactoring can be. Thus it will be divided into smaller sub-tasks. It's not totally impossible that part of the work will be delayed to next release.

Well .. as an enhancement (P3 or otherwise) I can see it being dropped and definitely if it misses the fork,
and I don't get why you can't do it here. And if it isn't done the JEP isn't really ready.
I already pasted the patch for Component.java and it took about 60 seconds to do that.
Then yes, you would have to deal with the fact that now you need to reapply your automated tool to the file but this is just work you'd have to have done anyway if it was already refactored.

I only *noticed* Component and Container. And stopped there to raise the question. How many more cases are there ?

-------------

PR: https://git.openjdk.java.net/jdk/pull/4073