Hi, We're also investigating this possibility, but we have doubts whether ForkJoinPool would boost performance significantly. The amount of code changes to remove the guava dependency should be quite serious as well: searching the project for the appropriate imports returns about 600 entries.
In the long run, guava dependency removal might be tempting to allow smooth migration to virtual threads (introduced in project Loom - Java 21), but that would probably take a significant amount of time as well. To keep track of this investigation, JIRA QPID-8664 was created: https://issues.apache.org/jira/browse/QPID-8664 Best Regards, Daniil Kirilyuk On Sat, 6 Jan 2024 at 09:53, Nikheel Patel <nikheel.pate...@gmail.com> wrote: > I was using/exploring Qpid Broker-J 9.1.0 > while exploring the source code of *Qpid Broker-J 9.1.0 tag*. > I found that google guava's concurrency API is used. > After exploring it bit more i realized that we can easily use java's > *CompletableFuture > and ForkJoinThreadPool* instead of *ListenableFuture, AbstractFuture, > ListeningExecutorService, SettableFuture, MoreExecutors,...* also guava's > ByteStreams can be replaced with java's built-in methods in few places. > > Due to the work-stealing capability of *ForkJoinThreadPool* i think it can > give performance boost to qpid-broker-j. > > The only possible down-side I can think of is that *CompletableFuture *is > concrete implementation rather than abstract class or interface*. *Maybe > someone can suggest an improvement on this idea which takes care of > possible down-side i mentioned earlier. > > possibly one less dependency for the project in the long run as well. >
