I guess that before Loom becomes a reality (i.e. in a few years), there is no plan for a non-reactive “async” driver anymore. Jumping to a reactive approach is kinda a big deal (this is an understatement). I get that one can isolate it at the mongodb level turning every subscriber result into a CompletionStage or the like, but that’s still a significant refactoring effort. Am I alone with those concerns? Started thinking about it more recently because the next release (5.0) won’t be supported by 3.12.x.
While the 3.12 driver won’t support all the new features of MongoDB 5.0, we are still running the entire 3.12 test suite against 5.0 and ensuring that all the tests still pass.
As for the callback-back async driver, I wouldn’t say you’re alone, but we did not see much usage of this driver, as almost everyone doing async standardized on Reactive Streams.
Regards,
Jeff
That’s good news.
The callback-style async driver is a bit cumbersome, but a CompletableFuture-style one, similar to what Lettuce does for Redis, could have been a good alternative. With Loom in the picture, some will definitly resist the jump to the Reactive approach anyway.
At the time that we created the async driver our minimum supported Java version was 1.6, so CompletableFuture wasn’t an option. And by the time Java 8 became our minimum supported version (about a year ago), the Reactive Streams driver was already well established. This is the first time I recall anyone asking for a CompletableFuture-based API (though I may have forgotten). Not that it wouldn’t be useful to some, but there would be a cost burden in maintaining it.
Regards,
Jeff
1 Like