Without L104, array is empty, and L108 and L112 fill zeros into buffers.
I also just noticed that the dummy class loaders are only used in
samevm. When running as othervm or standalone, findClass() method is
never called.
It seems in othervm mode, the TestClass.class is in the same directory
as the main class and it's loaded directly by the URLClassLoader (?).
I've updated the code changes to first rename the compiled file, so that
the URLClassLoader will be find it. The new test runs OK for both samevm
and othervm. I've even added a counter to make sure dummy class loader
get used.
http://cr.openjdk.java.net/~weijun/7054428/webrev.01
JPRT also OK at --
http://jprt-web.us.oracle.com/archive/2011/06/2011-06-14-140902.ww155710.jdk//JobStatus.txt
Thanks
Max
On 06/14/2011 08:53 PM, Alan Bateman wrote:
Weijun Wang wrote:
Hi Alan
The last excluded test in jdk_security1:
http://cr.openjdk.java.net/~weijun/7054428/webrev.00/
I'm not an NIO expert, but the test looks too wrong. Is there any
chance for it to pass in the last 8 years?
I don't think L104-105 is needed. I agree with L109 and L113. The last 3
buffers also have the wrong position.
I haven't studied this test before but it looks to me that it's not
actually doing what it should be and the dummy class loaders aren't
actually loading Test.
My guess the test failure in samevm mode is because of the mapped byte
buffer and also leaving the file open in readClassFile.
-Alan.
