pjfanning opened a new pull request, #1384:
URL: https://github.com/apache/pekko-http/pull/1384
### Motivation
Java generics are invariant, so these Java API parameters reject realistic
arguments:
- `completeOKWithFuture(CompletionStage<RequestEntity>)`:
`entity.toStrict(...)` returns a `CompletionStage<HttpEntity.Strict>`, which
cannot be passed
- `JsonEntityStreamingSupport` /
`CsvEntityStreamingSupport.withFramingRendererFlow(Flow<ByteString, ByteString,
NotUsed>)`: a framing flow that materializes anything other than `NotUsed` is
rejected
This is suggested PR 5 of #1378. The `Optional<ContentType>` item from that
list is already in #1380.
### Modification
- `RouteDirectives.completeOKWithFuture`: `CompletionStage<? extends
RequestEntity>`
- `RouteDirectives.completeWithFuture` and `completeWithFutureStatus`:
`CompletionStage<? extends HttpResponse>` / `CompletionStage<? extends
StatusCode>`, for consistency (Java callers rarely hold their subtypes)
- `JsonEntityStreamingSupport` /
`CsvEntityStreamingSupport.withFramingRendererFlow` (javadsl abstract methods
and the scaladsl overrides): `Flow<ByteString, ByteString, ?>`. The scaladsl
implementations map the flow's materialized value to `NotUsed`, since the
stored framing renderer is a `Flow[ByteString, ByteString, NotUsed]`. That
value was never exposed, so nothing is lost.
The `CompletionStage` wildcard is widened with a small private helper before
the existing `asScala` conversion. This is safe because the stage is only read.
The older `scala.concurrent.Future` overloads (`completeWithFutureResponse`,
`completeOKWithFutureString`, `completeWithFutureStatus(Future)`) are unchanged.
MiMa reports `IncompatibleSignatureProblem` for the 7 changed methods
because the generic signature changed. The erased JVM signatures are unchanged,
so existing compiled callers still link and existing Java sources still
compile. The excludes are in a new
`java-future-and-framing-wildcards.excludes`. One caveat: the javadsl
`JsonEntityStreamingSupport` / `CsvEntityStreamingSupport` are abstract classes
without `@DoNotInherit`. A third-party subclass would need to update its
`withFramingRendererFlow` override signature. That should be rare, since
instances come from `EntityStreamingSupport.json()` / `csv()`.
No docs change: the methods behave the same, they just accept more argument
types.
### Result
Java callers can pass a `CompletionStage` of a subtype, and a framing
renderer with any materialized value, without casts or `mapMaterializedValue`.
### Tests
- `sbt http/compile http/mimaReportBinaryIssues`: passed with the new
excludes
- New Java tests, **not run locally** (machine overloaded), left to CI:
- `RouteDirectivesTest.testCompleteWithFutureAcceptsResultSubtypes`:
`completeOKWithFuture` with a `CompletionStage<HttpEntity.Strict>`,
`completeWithFuture` with a `CompletionStage<? extends HttpResponse>`, and
`completeWithFutureStatus` with a `CompletionStage<? extends StatusCode>`, each
checking status and entity
- new
`EntityStreamingSupportTest.withFramingRendererFlowAcceptsAnyMaterializedValue`:
JSON and CSV `withFramingRendererFlow` with a `Flow<ByteString, ByteString,
String>`, checking that `getFramingRenderer()` renders `<a|b>`
- both fail to compile against the old signatures
- `http/scalafmt` and `http-tests/Test/javafmt` (JDK 17) applied;
`http-tests/Test/headerCreate` added the header to the new test file
### References
Refs #1378
--
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]
