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

[Weijun Wang]

> Now back to the original issue. My guess is that it was failing in
> samevm mode because readClassFile leaves the file open and it would
> be good to fix that. We might also need to do something with the
> file  mapping.

But the current test passes without closing the stream, even on Windows. 
I guess it's because the file opened is not in scratch directory and 
needs not be cleaned up.

If we have to close the stream/channel, it seems the references need to 
saved in DummyClassLoader's static fields and cleaned up in another 
static method called in a finally clause of the test's main method.

The reason the original test failed in samevm is that 
buffers[DIRECT_BUFFER].flip() is not called and its remaining() is zero, 
and causes the error:

   java.lang.ClassFormatError: Truncated class file

Thanks
Max



On 06/15/2011 06:56 PM, Alan Bateman wrote:
> Weijun Wang wrote:
>> 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
> I assume the original author just didn't realize that delegation
> meant that TestClass was being loaded by the parent loader.
>
> Anyway, the changes look okay to me. I guess an alternative would be
> to compile TestClass into a different directory rather than renaming
> it.
>
>
> -Alan