4 ms·
I'm not a Java developer, but isn't RxJava the current best practice around managing concurrency in Java? I thought the consensus was that manually dealing with
by JSavageOne 6y ago
I'm not a Java developer, but isn't RxJava the current best practice around managing concurrency in Java? I thought the consensus was that manually dealing with thread creation is too error-prone and unmanagable.
- sk5t 6y agoRxJava has some nice tools for async buffering, debounce, etc., but it pays to understand CountdownLatch, Semaphore, Mutex, ExecutorService, etc., and I would definitely not consider RxJava a substitute for other things. Do avoid anything related to the hoary old Java "Future" class, though. CompletionStage or get out!
- abhishekjha 6y agoWe are using the Akka framework so as to not to have to deal with threads directly. Message passing and immutable objects simplify a lot while adding one more abstraction layer.
- vips7L 6y agoNo, ExecutorServices are the current best practice around managing concurrency in Java. RxJava is only something you should use if you have specific performance requirements (with data to back it up), and you need the Observable pattern.
- pjmlp 6y agoRxJava got hyped in Android before Google went with Kotlt first, now they are into co-routines and depending on the Jetpack project, Java developers might still be able to use it, or be forced into Kotlin.
- bassman9000 6y agoNot quite. There were plenty and simpler abstractions to easily manage concurrency before, without even touching Thread. As someone has mentioned, Executors, ExecutorService, ThreadPools, ... RxJava feels like an unnatural port from single-threaded mindsets.