On Wed, 3 Apr 2024 10:52:10 GMT, Alan Bateman wrote:
> This is a test-only addition to add a test for virtual threads invoking a
> synchronized native method and invoking a native method that enter/exits a
> monitor with JNI MonitorEnter/MonitorExit. The test has been in the loom repo
> for so
Think about `flatMap` (which filter is a special case of), this is
one-to-many function that can also return 1 or 0 elements for each input.
So it makes sense to include 0 as "many".
Filter isn't many-to-... At all, at no point it collapses a subsequence of
elements, it only works on one element a
On 24/04/07 9:11 AM, Viktor Klang wrote:
Hi Ernie,
"Many" in this case refers to "N", which is "0 ... N",
OK, I was wondering about "many" including "0".
so I'd say while it is techincally correct as-is, perhaps more precise
would be to say "1-to-0..1" gatherer, since for every element in,
th
Hi Ernie,
"Many" in this case refers to "N", which is "0 ... N", so I'd say while it is
techincally correct as-is, perhaps more precise would be to say "1-to-0..1"
gatherer, since for every element in, there is 0 or 1 element out.
Many-to-one would be 0..N -> 1, which means that an empty input
This is about what might be a minor doc issue.
In https://openjdk.org/jeps/473 it says
As another example, |Stream::filter| takes a predicate that determines
whether an input element should be passed downstream; this is simply a
stateless one-to-many gatherer.
Shouldn't this be "many-to-one"?
