Moving the internal classes to com.sun.java.accessibility.internal is right as com.sun.java.accessibility is a supported API. Sean is right that no need to specify /secure=java.lang.SecurityManager.
Mandy > On Jul 14, 2015, at 11:57 PM, Sean Mullan <sean.mul...@oracle.com> wrote: > > You don't need to add the /secure option to jtreg. That's overriding jtreg's > SecurityManager and causing you to have to grant jtreg permissions to read > files in the jtreg.security.policy file. Just add the /java.security.policy > option -- this will use jtreg's SecurityManager which is sufficient for > testing this bug, and then you won't need the jtreg.security.policy file. > > Looks good otherwise. > > --Sean > > On 07/13/2015 06:34 PM, Pete Brunet wrote: >> Please review the webrev for >> https://bugs.openjdk.java.net/browse/JDK-8051626 >> >> http://cr.openjdk.java.net/~ptbrunet/JDK-8051626/webrev.00/ >> >> This is so the the Java Accessibility Utilities package, >> com.sun.java.accessibility.util, can be run with the security manager >> active but the non-public accessibility packages won't, i.e. >> com.sun.java.accessibility.internal and >> com.sun.java.accessibility.util.internal. >> >> Running the regression test proves that there will be a security >> exception when using a method of com.sun.java.accessibility.util before >> the fix but not after. >> >> Pete >>
