Question: I have the following interface:

```
public interface Result<T extends Serializable> extends Serializable{
    T getResult();
}

```

With that interface, I can not define a variable of type

```
Result<List<Integer>>

```

because List is not serializable.

However, if I change the interface to this:

```
public interface Result<T> extends Serializable{
    T getResult();
}

```

It now becomes impossible to implement, with compile time checking, because there is no guarantee that T is serializable, and the whole point of the class is to store the result so that I can get it back later, possibly after a transfer over the internet.

My question is this, is there a way to declare a variable so that it is of two types, or is there some other way to do this that I am not seeing? So, maybe something like:

```
(List<Integer> extends Serializable) value = new ArrayList();

```

I am trying to put as much of the burden of this problem on the implementation, so that future consumers of this interface are unaware of the problem.

Thanks for your help!

Here is a more detailed example of what I am trying to do:
I am calling a server, The result of which I want to store in a result object, but I do not want to have to deal with casting. So, each method that can be called on the server will define the type of the result by using generics. This result object will also store other meta-data about the result, for example maybe there was too much information to return. In many cases I want to use a list, but the List interface is not serializable, although many of the implementations are.

So, how to I specify that the type used must be Serializable, but still allow for a List(and not a specific implementation of List) to be used?

Answer: 
Although the List interface doesn't implement Serializable, all of the built-in Collection implementations do. This is discussed in the Collections [Implementations tutorial](http://java.sun.com/docs/books/tutorial/collections/implementations/index.html).

The Collections Design FAQ has a question ["Why doesn't Collection extend Cloneable and Serializable?"](http://java.sun.com/javase/6/docs/technotes/guides/collections/designfaq.html#5) which talks about why Sun designed it without extending Serializable.
You kind of can, I think:

```
public class Thing<T extends Serializable> implements Serializable {
    private static class Holder<V extends Serializable> {
        private final V value;
        private Holder(V value) {
            this.value = value;
        }
    }
    private Holder<? extends List<T>> holder;
    private <V extends List<T> & Serializable> void set(V value) {
        holder = new Holder<V>(value);
    }
}

```

Does that look ugly enought for you?

Can I suggest that you do not attempt to enforce implementing `Serializable` using the Java static type system? It's only an interface because annotations weren't about back then. It's just not practical to enforce it. OTOH, you could enforce it using a type checker that does static analysis in a closed system.