daniellansun commented on PR #2986: URL: https://github.com/apache/groovy/pull/2986#issuecomment-6457494125
Thank you for the careful re-read — these are very helpful catches. I will address them on this PR as follows: 1. **`grepParallel`** — fix both issues here: null-check only `self` so `[1, null, 2].grepParallel(null)` matches sequential `grep(null)`, and treat `isCase` results with Groovy truth (`castToBoolean`) so custom filters align with sequential `grep`. 2. **`maxParallel` and nulls** — match sequential `max(Comparator)` (skip nulls; `[null, null]` without calling the comparator). I will keep `minParallel` matching sequential `min` as it already does, and make the asymmetry explicit in comments/docs so it does not diverge silently. 3. **Per-element `Pool.withCurrent`** — given the light-callback cost you measured, I will move to a worker thread factory that carries the owning `Pool`, with `Pool.current()` falling back to the current worker’s pool, so nested calls stay on the pool without rebinding every element. I will include a JMH (or equivalent) number for a light workload with that approach. 4. **Interrupt semantics** — add a short note to `core-parallel-collections.adoc` about executor-path interruption on short-circuit / sibling failure (and that it can close an `InterruptibleChannel`). 5. **`groupInOrder`** — switch to `LinkedHashMap` so keys follow first-seen order like sequential `groupBy`. **Housekeeping:** I will update the JIRA description to match the current design (no compensation). On whether this should go to 6.0.x (and the null-handling release-notes entries), I will confirm shortly and follow up here. Thanks again for the detailed notes. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
