Java JCache String key vs Composite key

Question

I am using JCache for caching web responses. The cache key includes following fields:

• controller: String
• action: String
• parameters: Array

I created ResponseKey class and use it as a cache key type:

public class ResponseKey implements Serializable {

    private String controller;
    private String action;
    private Object[] parameters;

    @Override
    public int hashCode() { // IMPL }

    @Override
    public boolean equals(Object obj) { // IMPL }
}

Sample codes (works fine):

JCache<ResponseKey, byte[]> cache = ...
ResponseKey key = new ResponseKey("category", "list", new Object[] { 1 });
cache.put(key, bytesContent);

Another approach is using String as a cache key type:

JCache<String, byte[]> cache = ...
String key = "/category/list/1";
cache.put(key, bytesContent);

Since String type is lighter than ResponseKey type for serialization/deserialization.

My question is: Should I use String key instead of ResponseKey key?

Answer 1

There is probably no exact answer to this question as there are pros and cons for each way. Both will work.

• -> String: A key class is less flexible in case of different cache items with entirely different parameter sets.
• -> String: A key class has more overhead at cache lookup as you probably come with an URL and there is no need to parse the entire URL in case of a cache hit when using String.
• -> Key class: it is more clear from the code what is intended to be used as key and it provides more type safety. E.g. you can't accidentally miss a /.
• -> String: A string has an overhead of one object per key while your key class takes about 5 or more.
  But be aware that this may turn into the opposite when the same actions, controllers and maybe even parameter values are used very often. In this case different key instances may share the selfsame string for actions and so on. This might conserve significant memory when many items are cached. However, most likely the cache content will be much larger, so this usually does not carry weight unless deduplication also applies to your cached content.

=> so I would recommend to use String since it has more advantages.

Note: in other languages with complex value types there would be another preferable option to use a value type that consists just of your String but provides additional type safety as well as methods to (de)compose its components.