mdedetrich commented on code in PR #361:
URL: https://github.com/apache/incubator-pekko/pull/361#discussion_r1209441567
##########
CONTRIBUTING.md:
##########
@@ -533,9 +533,7 @@ Scala has proven the most viable way to do it, as long as
you keep the following
1. If the underlying Scala code requires an `ExecutionContext`, make the Java
API take an `Executor` and use
`ExecutionContext.fromExecutor(executor)` for conversion.
-1. Make use of `scala-java8-compat` conversions, see
[GitHub](https://github.com/scala/scala-java8-compat)
- (eg. `scala.compat.java8.FutureConverters` to translate Futures to
`CompletionStage`s).
- Note that we cannot upgrade to a newer version scala-java8-compat because
of binary compatibility issues.
+1. Use `org.apache.pekko.util.FutureConverters` to translate Futures to
`CompletionStage`s.
Review Comment:
The whole point of having it private is so that we can completely drop these
API's when we drop support for Scala 2.12 without having to break users.
I think the discussion of making these API's relevant is a bit of a red
herring (i.e. 红鲱鱼). For me the real question is whether
https://github.com/lomigmegard/pekko-http-cors and
https://github.com/pjfanning/aws-spi-pekko-http should be included within Pekko
itself. While Pekko having dependencies is generally not a problem, the issue
in this case is that these dependencies use Pekko while Pekko happens to also
rely on these dependencies.
--
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]
