pjfanning commented on issue #3712:
URL: https://github.com/apache/pekko/issues/3712#issuecomment-6439498835
Status and remaining candidates after #3713 and #3714 (merged) and #3717
(open; widens the stream javadsl `Function`/`Function2`/`Creator`/`Predicate`
parameters and `CompletionStage` results of async functions):
**1. Element-type variance on `Graph` parameters (stream javadsl)** - about
150 parameters still take an invariant shape:
| Parameter | Count | Widen to |
|---|---|---|
| `that`/`those`/`secondary`: `Graph[SourceShape[Out], …]` (`concat`,
`merge`, `zip`, `interleave`, `orElse`, `prepend`, …) | ~90 |
`Graph[SourceShape[? <: Out], …]` |
| `that`/`sink`: `Graph[SinkShape[Out], …]` (`to`, `alsoTo`, `wireTap`,
`divertTo`, …) | ~40 | `Graph[SinkShape[? >: Out], …]` |
| other `source`/`g` parameters with `T`/`U`/`In` | ~20 | same pattern |
This one shows up in everyday Java code: concatenating a `Source<Integer>`
onto a `Source<Number>` needs `Source.upcast` today, and
`strings.to(objectLoggingSink)` with a pre-typed `Sink<Object, …>` does not
compile. Since Scala already declares `SourceShape[+T]`, `SinkShape[-T]` and
`Graph[+S, +M]`, the method bodies should need few changes. Only the generic
signatures change, so it stays binary compatible.
**2. Wildcards inside the results of widened functions (stream javadsl)** -
the same treatment as the `CompletionStage` change:
- `? <: Optional[T]` (26 places, e.g. `mapOption`, `unfold`, `statefulMap`
`onComplete`) → `Optional[? <: T]`
- `? <: java.lang.Iterable[T]` (10, `mapConcat`/`statefulMapConcat`) →
`Iterable[? <: T]`
- `? <: Pair[S, T]` (9) → `Pair[? <: S, ? <: T]` (`japi.Pair` is invariant
even in Scala)
These touch the same lines as #3717, so they could be added there.
**3. Function parameters in the other modules' javadsl:**
| Module | Invariant function params |
|---|---|
| persistence-typed | ~45 |
| actor-typed | ~21 |
| stream-typed (`ActorFlow`, `ActorSource`, `ActorSink`) | ~17 |
| actor-testkit-typed | ~5 |
| cluster-typed | 1 |
Only methods users call, such as builders and factories, can be widened.
Abstract methods that users override, such as handlers in
`EventSourcedBehavior`/`AbstractBehavior` subclasses, can't change their
generic signature without breaking existing Java subclasses ("name clash: same
erasure"), so each module needs a manual review - probably one PR per module,
starting with stream-typed.
--
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
