On Thu, 9 Oct 2025 21:34:18 GMT, Xueming Shen <[email protected]> wrote:
>>> Does ParameterizedTest support vm/platform classloader isolation for each
>>> parameterized test run against the same test with different parameters?
>>
>> I should have been clearer in my comment. The suggestion to use a
>> ParameterizedTest is to exercise a custom class loader using
>> super.defineClass with different buffers (direct, heap, position != 0, ...)
>> so that it exercises the "non-trusted" cases.
>>
>> You are right that testing the platform class loader (as a trusted class
>> loader) will require opening java.lang.
>
> The test case has been updated to use @ParameterizedTest for the user-defined
> classloader, with the following variants.
>
>
> static Stream<Arguments> bufferTypes() {
> return Stream.of(
> arguments(ARRAY_BUFFER, 0, false),
> arguments(ARRAY_BUFFER_READONLY, 0, true),
> arguments(DIRECT_BUFFER, 0, false),
> arguments(DIRECT_BUFFER_READONLY, 0, false),
> arguments(ARRAY_BUFFER, 16, false),
> arguments(ARRAY_BUFFER_READONLY, 16, true),
> arguments(DIRECT_BUFFER, 16, false),
> arguments(DIRECT_BUFFER_READONLY, 16, false)
> );
> }
>
>
> I keep the built-in classloader testing asis in the same test file for now.
> Let me know if you have a strong opinion to split it out.
Good, but I think we think we need to buffers created with
ByteBuffer.allocateDirect and ByteBuffer.allocate. Also there are 4 arena types
so allocating from each would make for a more complete test.
One suggestion, up to you, is create all the buffers in the method source. That
would allow additional buffers to be added without needing to change the test
method to special case each one. (For the confined arena case it just means you
can't close, but that's okay for this test).
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/27569#discussion_r2419560540
