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
