Hello, Anthony. I've updated the fix: http://cr.openjdk.java.net/~pchelko/8025440/webrev.01/
Now the CopyClassFile utility is also copying the inner classes. It also supports class name in different packages. With best regards. Petr. On Sep 27, 2013, at 4:05 PM, Petr Pchelko <petr.pche...@oracle.com> wrote: > Hello, Anthony. > >> Note that the new utility class has limitations. For instance, it won't copy >> inner classes belonging to the main copied class. I suggest to document >> this, or implement this. Also, I suggest to add a message to the >> IllegalArgumentException thrown from the utility class. > > Ok, I'll fix that and resend the webrev. > >> I have a question though, why do we need it in the first place? Wouldn't it >> be sufficient to just override the checkPermission() method in the inner >> SecurityManager instance in the test itself? Why move it to a top-level >> class? > If we just override the CheckPermission method the SecurityManager itself > becomes an untrusted code. So the SecurityManager would check access to > checkPermission by invoking checkPermissiom. So we would get an infinite > recursion. > To avoid this the SecurityManager should be loaded from the boot classpath. > But in jtreg comments we are not able to determine the path to the folder > which the SecurityManager was compiled to, it's possible only in runtume. So > we need to copy the SecurityManager class to some temp location and than use > it in VM arguments for an actual test. > > With best regards. Petr. > > On Sep 27, 2013, at 3:56 PM, Anthony Petrov <anthony.pet...@oracle.com> wrote: > >> Hi Petr, >> >> Note that the new utility class has limitations. For instance, it won't copy >> inner classes belonging to the main copied class. I suggest to document >> this, or implement this. Also, I suggest to add a message to the >> IllegalArgumentException thrown from the utility class. >> >> I have a question though, why do we need it in the first place? Wouldn't it >> be sufficient to just override the checkPermission() method in the inner >> SecurityManager instance in the test itself? Why move it to a top-level >> class? >> >> -- >> best regards, >> Anthony >> >> On 09/26/2013 01:11 PM, Petr Pchelko wrote: >>> Hello, AWT Team. >>> >>> Please review the fix for the following issue: >>> https://bugs.openjdk.java.net/browse/JDK-8025440 >>> The fix is available at: >>> http://cr.openjdk.java.net/~pchelko/8025440/webrev.00/ >>> >>> After SecurityManager.checkTopLevelWindow was deprecated in JDK-8008981 the >>> test fails. >>> This fix updates the test. The CopyClassFile util is introduced - it's >>> copying the class file into the specified directory in the test working >>> dir. This is needed to use the -Xbootclasspath, so that the new >>> SecurityManager could work. >>> >>> This is a test fix, no code is affected. >>> >>> With best regards. Petr. >>> >
