Indeed. I was reminded of a discussion [1][2] back in July when I saw this JEP candidate.
Now looking at it again, I guess we can easily prevent this risk once this JEP is implemented (so finalizers are no-op and attacks cannot happen even if the security manager is disallowed), and we might not need to remove finalizers before security managers as long as we can disable finalizers. https://mail.openjdk.java.net/pipermail/jdk-dev/2021-July/thread.html#5805 https://mail.openjdk.java.net/pipermail/jdk-dev/2021-July/005808.html On Tue, Nov 2, 2021 at 9:20 AM Alan Bateman <alan.bate...@oracle.com> wrote: > > On 02/11/2021 14:00, - wrote: > > On a side note, will the actual removal of finalization become a > > dependency of the actual removal of the security manager? I recall > > when the security manager was deprecated for removal, developers > > pointed out that there can be security risks with finalization in the > > mailing list. > > > I suspect you may be thinking about classes that specify SM permission > checks in their constructors. If so then no SM means the permission > check doesn't do anything. If finalization is disabled or removed then > the specific attack isn't a concern. So I think independent for that > discussion, assuming this is what you mean. > > -Alan
