Looks fine. Thank you.
--
best regards,
Anthony
On 09/27/2013 06:39 PM, Petr Pchelko wrote:
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.
