Java, declare variable with multiple interfaces?

Question

In Java, is it possible to declare a field/variable whose type is multiple interfaces? For example, I need to declare a Map that is also Serializable. I want to make sure the variable references a serializable map. The Map interface does not extend Serializable, but most of Map's implementations are Serializable.

I'm pretty sure the answer is no.

Follow up: I'm fully aware of creating a new interface that extends both Map and Serializable. This will not work as existing implementations (such as HashMap) do not implement my new interface.

Answer 1

public interface MyMap extends Map, Serializable {
}

will define a new interface that is the union of Map and Serializable.

You obviously have to then provide a suitable implementation of this (e.g. MyMapImpl) and you can then provide variable references of the type MyMap (or Map, or Serializable, depending on the requirements).

To address your clarification, you can't retrofit behaviour (e.g. a serializable map). You have to have the interface and some appropriate implementation.

Answer 2

You can achieve this by making your own Interface, which extends the interfaces you want

public interface SerializableMap<K, V> extends Map<K, V>, Serializable {

}

Answer 3

You can do it with generics, but it's not pretty:

class MyClass<T,K,V extends Serializable & Map<K,V>> {

   T myVar;

}

Answer 4

There is no need to declare the field/variable like that. Especially since it can only be tested runtime and not compile time. Create a setter and report an error should the passed Map not implement Serializable.

The answers recommending that you create your own interface are of course not very practical as they will actively prohibit sending in things that are Maps and Serializable but not your special interface.

Answer 5

You can't really do it if you want to keep using the existing Map implementations.

An alternative would be to make a helper class, and add a method like this one:

public static Serializable serializableFromMap(Map<?, ?> map) {
 if (map instanceof Serializable) {
  return (Serializable)map;
 }
 throw new IllegalArgumentException("map wasn't serializable");
}

Answer 6

I voted up Brian's answer, but wanted to add a little higher-level thought..

If you look through the SDK, you'll find that they rarely (if ever) pass around actual collection objects.

The reason for that is that it's not a very good idea. Collections are extremely unprotected.

Most of the time you want to make a copy before passing it off and pass the copy so that any modifications to the collection won't change the environment for something else that's relying on it. Also, threading becomes a nightmare--even with a synchronized collection!

I've seen two solutions, one is to always extract an array and pass it. This is how the SDK does it.

The other is to ALWAYS wrap collections in a parent class (And I mean encapsulate, not extend). I've gotten into this habit and it's very worth while. It doesn't really cost anything because you don't duplicate all the collection methods anyway (actually you rarely duplicate any of them). In fact what you end up doing is moving "Utility" functionality from other classes distributed all over your code into the wrapper class, which is where it should have been in the first place.

Any method with a signature that matches "method(collection,...)" should almost certainly be a member method of that collection, as should any loops that iterate over the collection.

I just have to throw this out every now and then because it's one of those things I didn't get for a while (because nobody championed the concept). It always seems like it's going to have some drawback but having done this for a while and seeing the problems it solved and code it eliminated, I can't even imagine any possible drawbacks myself, it's just all good.

Answer 7

It's possible to do this using some generics tricks:

    public <T extends Map<?,?> & Serializable> void setMap(T map)

The above code uses generics to force you to pass a map which implements both interfaces. However, note that a consequence of this is that when you actually pass it the maps, they will probably need to be either marked as serializable or of a map type which is already serializable. It also is quite a bit more difficult to read. I would document that the map must be serializable and perform the test for it.

Answer 8

Nope, you'll pretty much need to cast.