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
