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. >>
