code review request: 7054428: test/java/security/SecureClassLoader/DefineClassByteBuffer.java error

[Weijun Wang]

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.