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

[Peter Levart]

On 15/06/2021 10:35, Rafael Winterhalter wrote:
> Hi Peter,
> thanks for the suggestion. Byte Buddy still baselines to Java 5, 
> unfortunately method handles are not an option at this point. I am 
> looking into writing a Byte Buddy build plugin that discovers calls to 
> PrivilegedAction.run and wraps those in a reflection-based 
> AccessController invocation. This does however not cover all corner 
> cases. I have tabled the problem for now and will see how and if other 
> libraries adapt.
> Best regards, Rafael


Maybe the problem would be clearer if you described what Byte Buddy 
normally does with code that uses AccessController.doPrivileged. Does 
Byte Buddy also use AccessController.doPrivileged internally? What I 
mean is AccessControllerWrapper could be an independent library, 
compiled for at least JDK 7 target. Apps or libraries that want to be 
deployable across JDK 7 ... JDK X (where X is the release which removes 
AccessController API) could use this library instead of directly 
invoking AccessController API to achieve that. Apps that still want to 
run on JDK 5 or 6 probably are not also targeting JDK X at the same time 
right? Such apps can keep using AccessController API. Now how does 
ByteBuddy come into this picture? What does it do with code that either 
uses AccessController API and what would it have to do with code that 
uses AccessControllerWrapper instead?

Regards, Peter


>
> Am Di., 15. Juni 2021 um 09:20 Uhr schrieb Peter Levart 
> <peter.levart at gmail.com <mailto:peter.levart at gmail.com>>:
>
>     Hi Rafael,
>
>     On 13/06/2021 22:28, Rafael Winterhalter wrote:
>     > Furthermore, it is difficult to create a working facade for
>     dispatching to
>     > the security manager only if it is available. Methods like
>     > AccessController.doPrivileged are caller sensitive and by adding
>     a utility
>     > to a library, this utility would leak to any potential user. It
>     would
>     > therefore require package-private dispatchers for any relevant
>     package,
>     > which would lead to a lot of copy-paste to retain backwards
>     compatibility
>     > (given that a library cannot assume to be run as a module).
>
>
>     Here's my attempt / idea for such a utility which uses
>     MethodHandles.Lookup as an additional argument in order to
>     dispatch to a
>     caller-sensitive AccessControler.doPrivileged:
>
>     https://gist.github.com/plevart/ec333cb2c3a0306793961e8fb223bc98
>     <https://gist.github.com/plevart/ec333cb2c3a0306793961e8fb223bc98>
>
>
>     I don't know whether this helps much in your situation because apps
>     currently using AccessControler.doPrivileged would have to 1st
>     migrate
>     to using such utility wrapper so you would have to provide an
>     independent module containing it. But it is a possible solution in
>     the
>     long run when AccessControler API is removed from JDK.
>
>
>     Regards, Peter
>