Thank you for doing this; it is much clearer now. Looks good. On Oct 1, 2013, at 10:19 PM, John Rose <john.r.r...@oracle.com> 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 > > — 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-dev@openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev _______________________________________________ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
