Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
In top-level API don't require materializer where it's just ignored afterwards #1464
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.
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.