title: Java generics and Serializable
body: <p>We created an abstract class that we use for dealing with Redis (set/get values), that looks like follows:</p>
  
  <pre><code>public abstract class AbstractCachedSupport&lt;T extends Serializable&gt; {
      protected T get(CacheKey key, Supplier&lt;T&gt; supplier) {...}
      // ...
  }
  </code></pre>
  
  <p>What I'm not happy about is that we cannot use interfaces like List, Map when extending this class:</p>
  
  <pre><code>public class CachedMap extends AbstractCachedSupport&lt;Map&lt;String, Integer&gt;&gt;
  </code></pre>
  
  <p>because they do not extend Serializable, so we have to always use concrete classes:</p>
  
  <pre><code>public class CachedMap extends AbstractCachedSupport&lt;HashMap&lt;String, Integer&gt;&gt;
  </code></pre>
  
  <p>Needless to say, this has its share of problems, when migrating from one concrete class to another for instance. It's also not something I would call best practice, but maybe that's just me.</p>
  
  <p>An alternative that gives us the flexibility to work with interfaces would be to remove the bounded typing and check at runtime whether T extends Serializable:</p>
  
  <pre><code>public abstract class AbstractCachedSupport&lt;T&gt; {
      public AbstractCachedSupport() {
          final Class&lt;T&gt; type = (Class&lt;T&gt;) ((ParameterizedType) getClass().getGenericSuperclass()).getActualTypeArguments()[0];
          if (!Serializable.class.isAssignableFrom(type)) {
              throw new RuntimeException("T must extend Serializable");
          }
      }
  
      protected T get(CacheKey key, Supplier&lt;T&gt; supplier) {...}
      // ...
  }
  </code></pre>
  
  <p>This leaves us without compile time checking on T extending Serializable, not a nice thing either.</p>
  
  <p>Do you know of any other way how we could solve this elegantly? Would you rather use the first one (bounded type parameter) or the second (runtime checking only)?</p>
  
  <p>A compromise would be to go for the first and always use a container class for holding the collection:</p>
  
  <pre><code>public class IntegerParamsContainer implements Serializable {
      private static final long serialVersionUID = 1L;
      private Map&lt;String, Integer&gt; map;
  }
  
  public class CachedMap extends AbstractCachedSupport&lt;IntegerParamsContainer&gt;
  </code></pre>
  
  <p>But this has in the end the same problem as the second: there is no compile time checking, the responsibility lies on the shoulders of the developers to always use collections that implement Serializable.</p>
  
  <p><strong>Edit:</strong>
  Some of the classes extending <code>AbstractCachedSupport</code> are Spring (version 4.1 currently) component classes and they are not called <code>CachedMap</code> or something similar, rather <code>CityAutocompleteDataBean</code>, <code>WrParamsDataBean</code> etc..
  If we add generics to these component classes, we'll end up with declarations such as:</p>
  
  <pre><code>@Inject
  private CityAutocompleteDataBean&lt;ArrayList&lt;String&gt;&gt;;
  @Inject
  private WrParamsDataBean&lt;HashMap&lt;String, WrData&gt;&gt;;
  </code></pre>
  
  <p>as opposed to</p>
  
  <pre><code>@Inject
  private CityAutocompleteDataBean;
  @Inject
  private WrParamsDataBean;
  </code></pre>
  
  <p>The reason for using <code>&lt;ArrayList&lt;String&gt;&gt;</code> and <code>&lt;HashMap&lt;String, WrData&gt;&gt;</code> will escape most developers when they'll see such lines of code. I also find it rather ugly, considering where we started and what we use this for.</p>
  
  <p>Nonetheless, this works as requested by me, thank you Jesper.</p>