On Mon, 4 Dec 2023 14:25:05 GMT, Viktor Klang <vkl...@openjdk.org> wrote:
>> Splits GatherersTest out to distinct files per built-in gatherer
>>
>> Fixes a test ordering issue for mapConcurrent which placed GatherersTest on
>> the ProblemList.
>>
>> Adding increased maxOutputSize for Gatherer-related tests to improve
>> debuggability.
>>
>> Lowering the composition threshold of
>> GathererTest.testMassivelyComposedGatherers to 256 to avoid SOE on
>> low-specc:ed machines.
>
> Viktor Klang has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Removing extraneous built-in gatherer test output
test/jdk/java/util/stream/GatherersMapConcurrentTest.java line 106:
> 104: );
> 105: assertEquals("expected", exception.getMessage());
> 106: assertNull(exception.getCause());
I assume it would be possible to add a comrade to this test for the wrapping
case too, e.g. if the mapper throws an Error.
test/jdk/java/util/stream/GatherersMapConcurrentTest.java line 245:
> 243: public void behavesAsExpected(Config config) {
> 244: for (var concurrency : List.of(1, 2, 3, 10, 1000)) {
> 245: final var expectedResult = config.stream()
I assume the loop is here because you can't have both a MethodSource and
ValueSource. I think I'd probably create a new method source for this, e.g.
static Stream<Arguments> configutatonAndConcurrency() {
return IntStream.of(1, 2, 3, 10, 1000)
.mapToObj(i -> i)
.flatMap(i -> configurations().map(c -> new Arguments(c, i)));
}
The advantage is that you'll have the parameter in the .jtr in the event of a
failure.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/16928#discussion_r1415671564
PR Review Comment: https://git.openjdk.org/jdk/pull/16928#discussion_r1415665826
