In top-level API don't require materializer where it's just ignored afterwards #1464
Conversation
…equest Requires a bit of an overload dance to ensure keeping binary compatibility. In Scala, also source compatibility is kept. On the Java side, the materializer arguments must be removed from invocations.
And fix bug that remoteAddress parameter was just ignored
akka-ci
added
validating
|
Test PASSed. |
There was a problem hiding this comment.
Definitely makes things a bit nicer. Hard to say for me what the chance is that we'd discover later that it would actually be nice to have access to a materializer in those places in the future - but probably low since this implementation works well and is now fairly mature.
|
@raboof yes, that's something I also thought about. For all of the shared pool APIs it just doesn't make sense to pass a materializer because it would just be unclear what it would mean if different invocations targeting the same shared pool would get different materializers. For |
|
Btw the reason I looked into this was that I saw code somewhere with multiple ActorMaterializers calling those shared pool methods and I wondered what would happen. |
It seems we had lots of these left over I guess from the early days where creating substreams required materializers to be passed. It seems no one cleaned that up so far. The changes were somewhat big to keep binary compatibility at least for a while. In Scala, it's binary and source compatible (if the materializer was passed implicitly). Java users need to remove the materializer argument.
Going forward, if we deprecate the old methods now and release another 10.0.x in October, we might think about cleaning those methods up for 10.1.0.