jdk.internal.reflect.ReflectionFactory and SecurityManager

[Claes Redestad]

On 2016-12-27 02:02, David Holmes wrote:
> Hi Claes,
>
> On 27/12/2016 9:48 AM, Claes Redestad wrote:
>> Hi,
>>
>> while perhaps an enhancement in isolation, I'll argue this to be a
>> blocker of or a sub-task of the redo of JDK-8062389 - a P2 bug that
>
> At this stage I would categorise it as one possible way to work around
> the issue that JDK-8062389 et al. ran into.

Agreed that if a better/simpler fix comes around we should run with it
and defer any further enhancemeents that's not critical, but I don't
think we should block this on the premise that there might be such a
fix around the corner.  Some due diligence is of course in order.

>
> The initialization sequence is fragile and is not a constant - different
> runtime options can affect the paths taken. So testing anything that
> introduces a change to initialization order is tricky, as there is no
> obvious set of tests that provide full coverage.
>

I agree that the initialization sequence is fragile and that we need to
test anything we do in it thoroughly, but I'd also assert that by
removing the need for doing SM.checkPermission calls (and the
doPrivileged calls needed to subdue them) we are likely to reduce
fragility, not increase it, ultimately decreasing the likelihood of
issues.

With more along the lines of what Peter is suggesting here we might
even be able to support lambdas in security managers one day:
https://bugs.openjdk.java.net/browse/JDK-8155659

Thanks!

/Claes