Java Generics and Type Safety

When I learned to code in Java, there was no such thing as generics to ensure type safety. Casting objects was part of the routine, and CastClassException was a familiar message. But Java now comes with Generics to help us avoid those runtime exceptions (when the application runs). Generics look like MyClass. Instead of having runtime exceptions, the compiler shows errors. Generics specify the type of what is within a container class (in this case MyClass). For example, we can define Cart to represent a cart of product from a shopping website.

Here are a few guidelines to use them:

1. Avoid using raw type. It is only there for backward compatibility. If necessary, use unbounded wildcards.

Cart cart; --> raw type: No!
Cart<?> cart; --> Unbounded wildcard type: Better!
Cart<E extends Item> --> Bounded type parameter: Better!
Cart<Item> cart; --> Generic: Better!

Wildcards are useful to ensure type safety even when the type is unknown. However, we cannot assume the type of object that we get out of our container… and we cannot put any element (other than null) into our container. If these restrictions are unacceptable, we can use generic methods or bounded wildcard types.

Cart<?> cart = Cart.empty();
cart.add(something); --> do not compile
Object something = cart.get(0); --> cannot assume the type of something

Unbounded wildcards are ok when nothing specific to the element type is used. For example, list.size() does need to know the type of objects in the list.

If for whatever reason, you use a raw type, a good practice is to test before with instanceof or isAssignedFrom.

2. Remove unchecked warning. If for whatever reason, you use raw types or cast such as:

Set<E> exaltation = new HashSet();
Set exaltation = new HashSet<>();

Add @SuppressWarnings(“unchecked”) on the smallest scope possible. For example, add the annotation on a method instead of a whole class. Otherwise, it will mask warnings you need to see. Also comment to explain why it is safe.

3. Use generic types – obviously – whether generic classes or methods. A static method can even be generic:

static <E> List<E> asList(E[] a)

However, a generic class cannot infer a static method, which means that:

class Cart<E extends Item> {
   public add(E item) {
     // E must extend Item because of the class declaration

   public static <E> List<E> asList(E[] a) {
     // E here does not depend from the class declaration.
     // the solution is: <E extends Item> static List<E> asList(E[] a)

4. Use bounded wildcard to add flexibility. Bounded wildcards look like: Iterable. It specifies the possible boundaries of the parameters. Let’s illustrate this. We want to create a Cart class:

public class Cart<E> {
   public Cart();
   public void add(E e);
   public E pop();
   public boolean isEmpty();
   public void addAll(Iterable<E> src) {
      for (E e : src)

Cart<Item> cart = new Cart<>();
Iterable<Fruit> fruits = … ; // Fruit extends Item
cart.addAll(fruits); // Won't work because Iterable<Fruit> cannot be converted to Iterable<Item>

The solution is:

public void addAll(Iterable<? extends E> src)

Use wildcard types on input parameters. Avoid bounded wildcard types as return types. Instead of providing flexibility, it would force you to use wildcard types in client code. You should not need to think about wildcards in the client code. If you have to return a wildcard, remember: Wildcards means “anything” so treat it that way. It implies you do not need to know what is manipulated. For example:

Cart<?> getCart();

It may be ok if what you do is simply call methods on the Cart object that can be type agnostic, such as getting the total sum of the cart:

Cart<?> cart = getCart();
double sum = cart.getSum(); // does not depend on the type of product in the cart

if a type parameter appears only once in a method declaration, replace it with a wildcard. If it’s an unbounded type parameter, replace it with an unbounded wildcard; if it’s a bounded type parameter, replace it with a bounded wildcard.

Generics are great, but it can quickly get messy with polymorphism… but this is for another post.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s