Hi @amishra ,
The Java RTO API was created to provide a very low and (importantly) predictable & consistent latency API to PubSub+ for those that still wanted to code in Java. So while JCSMP is also fairly low latency, it’s affected by garbage collection on the JVM which can affect latency consistency.
The use cases for Java RTO are the same as for the C-API… applications that are looking for the lowest latency and highest throughput. Typically we see this in financial trading apps and similar apps that are sensitive to latency and operate in “real time” as the RT stands for.
Keep in mind that although Java RTO is Java, being JNI, it looks very different than JCSMP (and “regular” Java) code. In order to keep the latency in check and not subject to garbage collection, the parts of your application that interact/process the messages should be coded in the same style. Otherwise you will introduce the same inconsistencies in latency via your application code.
If you are a Java developer looking for the most Java-like experience, I would suggest sticking with JCSMP… unless your use case demands the very lowest latency possible, which is what Java RTO was designed for. JCSMP is no slouch either, but it is subject to garbage collection.