Paul, The transformation you suggest is equivalent, but I reluctant to apply it. IMO, it doesn't add much value and current version is easier to read. Considering the current level of complexity in VA.isMemberAccessible I don't want to increase it even further :-)
Best regards, Vladimir Ivanov PS: thanks for looking into the fix. On 1/31/14 1:31 PM, Paul Sandoz wrote: > > On Jan 31, 2014, at 1:58 AM, Vladimir Ivanov <vladimir.x.iva...@oracle.com> > wrote: > >> http://cr.openjdk.java.net/~vlivanov/8033278/webrev.00/ >> https://bugs.openjdk.java.net/browse/JDK-8033278 >> >> The fix for 8032585 [1] introduced a regression: in some cases access check >> on a reference class is omitted. >> >> The fix is to ensure that access check on a reference class is always >> performed. >> > > 104 case PROTECTED: > 105 if ((allowedModes & PROTECTED_OR_PACKAGE_ALLOWED) != 0 && > 106 isSamePackage(defc, lookupClass)) > 107 return true; > 108 if ((allowedModes & PROTECTED) == 0) > 109 return false; > 110 if ((mods & STATIC) != 0 && > 111 !isRelatedClass(refc, lookupClass)) > 112 return false; > 113 if ((allowedModes & PROTECTED) != 0 && > 114 isSuperClass(defc, lookupClass)) > 115 return true; > 116 return false; > > Can lines 113 to 116 be reduced to: > > return isSuperClass(defc, lookupClass)); > > ? > > The shuffling of the code looks correct (and simpler), but i am fuzzy on the > nuances of access control. > > Paul. > >> Testing: regression test, jdk/test/java/lang/invoke/, >> jdk/test/java/util/stream, vm.defmeth.testlist, vm.mlvm.testlist, nashorn >> (unit tests, octane), groovy >> >> Thanks! >> >> Best regards, >> Vladimir Ivanov >> >> [1] http://cr.openjdk.java.net/~vlivanov/8032585/webrev.00/ > _______________________________________________ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
