On 10/1/13 10:19 PM, John Rose wrote:
Chris Thalinger suggested removing the new booleans from the changed "getDirectMethod"
call sites and instead put the intended usage into the method names, e.g.,
"getDirectMethodNoSecurityManager". The result is more clearly correct and maintainable.
Here is the respin:
http://cr.openjdk.java.net/~jrose/8025112/webrev.01
Looks good to me.
Mandy
— John
On Oct 1, 2013, at 3:15 PM, John Rose <john.r.r...@oracle.com> wrote:
This change updates the javadoc to reflect previous changes in the behavior of
the security manager, especially with respect to caller sensitivity.
It also adjusts some unit tests.
The key change is to the order of the security manager logic. The purpose is to align the
"bytecode behavior" of method handles more closely with the native behavior of the
corresponding bytecode instructions. This means that "fully trusted" method handles do
not incur security checks if they are equivalent to bytecodes that the user could have written.
The API spec. and security rules have been internally reviewed. This is a
review of implementation and unit tests.
http://cr.openjdk.java.net/~jrose/8025112/webrev.00
For more background, see my JavaOne presentation:
http://cr.openjdk.java.net/~jrose/pres/201309-IndyUpdate.pdf
Thanks,
— John
_______________________________________________
mlvm-dev mailing list
mlvm-...@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
