Thanks Alan, comments inline below.
On 26/10/2022 11:07 pm, Alan Bateman wrote:
:
What would make a significant difference is returning non null
ProtectionDomain's for JDK modules, so we can reduce the size of the
trusted computing base, to make our job smaller, hopefully that will
allow
On 26/10/2022 09:02, Peter Firmstone wrote:
:
That's correct, however some parts will bit rot faster than others,
historically some parts of the JDK are very slow to change, unless
someone comes through deliberately removing them, which I would hope
not, but I realise that new methods and
Thanks Alan,
That's correct, however some parts will bit rot faster than others,
historically some parts of the JDK are very slow to change, unless
someone comes through deliberately removing them, which I would hope
not, but I realise that new methods and classes might open new code
paths th
On 26/10/2022 02:58, Peter Firmstone wrote:
:
Using the existing permission check hooks in the JDK allows us to
significantly speed up our development efforts. Each time a
permission check hook is removed, we will need to replace it with
instrumentation. I was hoping this could be done in
Hi Sean,
I would be quite willing to undertake the work.
We have a decision to make based on when & how SM will be removed, for
obvious reasons, this decision will be delayed as long as possible:
1. Pull the plug on our existing Java software development efforts,
currently our software dep
When support for the Security Manager is removed, there would be little
benefit to keeping the permission checks inside the JDK, since it would
no longer be possible to set a Security Manager. Also, many APIs that
perform permission checks will likely be modified to no longer throw
SecurityExce
Would the OpenJDK team consider the following?
Where SecurityManager is invoked directly now, such as:
@SuppressWarnings("removal")
SecurityManager sm = System.getSecurityManager();
if (sm != null)
sm.checkPermission(new RuntimePermission("setFactory"));
Can
