JEP 411: Deprecation with removal would break most existing Java libraries

Peter Firmstone peter.firmstone at zeus.net.au
Fri Jun 18 03:24:54 UTC 2021


On 18/06/2021 1:18 pm, Peter Firmstone wrote:
>
> On 16/06/2021 11:18 pm, David Lloyd wrote:
>> On Mon, Jun 14, 2021 at 6:47 PM Peter Firmstone
>> <peter.firmstone at zeus.net.au> wrote:
>>
>>> Permission references can be replaced with Guard references (which
>>> Permissions are instances of).
>> I guess you've got something fairly complex in mind, could you give
>> some practical examples of how this would work?
>
>
> The same service provider mechanism encryption uses.  So 
> implementation may utilize authorization access check points without 
> any dependencies on current SecurityManager, Policy or Permission API's.


Eg GuardFactorySpi


>
> It's completely up to the implementation to determine how to manage.
>
>
>>
>>> The Permission implementations of Guard::check call SecurityManager, so
>>> checks will continue working as expected, but it allows us to intercept
>>> them and do something different.
>> What do you envision these checks looking like?  Where would the JDK
>> find these Guard instances?
>
>
> GuardFactory socketGuardFactory = GuardFactory.getInstance("SOCKET");
>
> Guard localhostConnectAccept = socketGuardFactory.orders("localhost", 
> "connect,accept");
>
> // Permission check
>
> localHostConnectAccept.check();
>
>
>
> GuardFactory runtimeGuardFactory = GuardFactory.getInstance("RUNTIME");
>
> Guard createClassLoader = 
> runtimeGuardFactory.orders("createClassLoader", null);
>
> // Permission check
>
> createClassLoader.check();
>
-- 
Regards,
  
Peter Firmstone
0498 286 363
Zeus Project Services Pty Ltd.




More information about the security-dev mailing list