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

Weijun Wang weijun at openjdk.java.net
Thu May 20 02:09:42 UTC 2021


On Wed, 19 May 2021 23:50:04 GMT, Phil Race <prr at openjdk.org> wrote:

>> 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 ?

I can make it a bug.

I don't want to do it here is because it involves indefinite amount of manual work and we will see everyone having their preferences. The more time we spend on this PR the more likely there will be merge conflict. There are just too many files here.

And no matter if we include that change in this PR or after it, it will be after the automatic conversion. In fact, the data about which cases are more worth fixing come from the automatic conversion itself. Also, as the manual work will be done part by part, if the automatic conversion is after it, there will be rounds and rounds of history rewriting and force push. This is quite unfriendly to the reviewers.

Altogether, there are 117 class-level annotations. Unfortunately, `java.awt.Component` is the one with the biggest class -- estimated number of bytes that the annotation covers is over 380K. In the client area, the 2nd place is `java.awt.Container`, and then we have `sun.font.SunFontManager`, `java.awt.Window`, and `java.awt.Toolkit` which are over 100KB, and other 25 classes over 10KB, and other 11 classes smaller than 10KB.

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

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


More information about the security-dev mailing list