| Lettuce uses such a different programming style I never tried it out. If you are looking for a Java Redis client, please try out all three: Lettuce, Jedis and Jedipus and pick the one that fits your taste. Because I'm not familiar with Lettuce, I'm just going to list my personal subjective design goals: * Robust transient error handling and retries. * Get out of the users way when sending a command and its arguments. The client should get the request data onto the wire as soon as possible. The client should not force the user to use any data structures for representing requests or responses. * Efficient pipelining support. Every client re-uses a single ArrayDequeue to optionally hold pending responses; no other data structures are created per request. See this gist for pipelined bulk loading https://gist.github.com/jamespedwards42/d03482c4b3515f78d1db.... * Frequent point releases in-sync with the Redis unstable branch. For example the new TOUCH command was added and released a day after being pushed to github at antirez/redis:unstable. * Redis Cluster focused. you can use just the client or pooled client executer, but the cluster executor is the real reason to use this library. The focus here is safety: partition handling and minimal locking only applied to migrating/unavailable slots. As well as performance (under the hood --> clientPools[slot].getClient). Also, things like load balancing requests across all of your nodes for a key/slot is nice :) * Make the development experience more enjoyable by using Java 8, Gradle and Docker. Hopefully this will attract other developers to the project so that a healthy community can grow. Goal is to move to Java 9 on rc1 in November, and to the Gradle component model and Kotlin instead of Groovy whenever that is ready as well. * Zero dependencies, none, nada. * I don't think this one really matters, but it is a pet peeve of mine. Avoid auto boxing by deserializing primitive long's directly from the socket input stream buffer. |