Stop Bitching About Type Erasure and Use It as an Excuse to Write Better Code

Type erasure has long been the bane of many a Java developer. For those not familiar with the term, here’s a condensed history. Generics were added to Java in 2004 with the release of Java 5. This feature allows you to specify type parameters to a class to provide tighter checks at compile-time, and facilitates generic coding in which you can, for example, declare a List of Integer as opposed to an unparameterized List where you have to typecast each element to the desired type. To make this work at run-time, type parameters are replaced by their bounds or the top-level class Object in the byte code (that’s type erasure), so that no new classes have to be created for parameterized types. This ensures that generics incur no run-time overhead. It can also be a pain in the ass if you allow it to be.

To illustrate this discomfort in the gluteus maximus, let’s consider this contrived example:

class EmployeeProcessor {
    ...
    public void processEmployees(List<String> employeeNames) {
        ...
    }

    public void processEmployees(List<Integer> employeeIds) {
        ...
    }

}

This is perfectly valid Java code. However, it won’t work at run-time because type erasure will replace List<String> and List<Integer> with List<Object>. Thus, we would have two methods with identical signatures. The Java compiler and Java IDEs know this, and will tell you about it early so that you don’t have to wait until run-time to find out.

What do we do about this? The obvious solution is to change the method names. For example, we can call one of them processEmployeesByName and the other one processEmployeesById. That will work just fine. But we all love us some overloading, so this is not a satisfactory solution. Cue the bitching and moaning and gnashing of teeth. There’s another solution that is much better: rename the argument types instead. For example, we can create the following two classes to replace the arguments to the two processEmployees methods:

class EmployeeNameList {
    private List<String> employeeNames;

    public EmployeeNameList() {
        employeeNames = new ArrayList<>();
    }

    // implement List methods you want to expose
}

class EmployeeIdList {
    private List<Integer> employeeIds;

    public EmployeeIdList() {
        employeeIds = new ArrayList<>();
    }

    // implement List methods you want to expose
}

Our EmployeeProcessor class now looks like this:

class EmployeeProcessor {
    ...
    public void processEmployees(EmployeeNameList employeeNames) {
        ...
    }

    public void processEmployees(EmployeeIdList employeeIds) {
        ...
    }

}

This version works at compile-time and run-time, and it’s better code than the original version. The meaning of the arguments to the processEmployees methods is clarified without relying on the formal argument names. In addition, type erasure forces us to wrap a List object in the EmployeeNameList and EmployeeIdList classes instead of extending the List class (which would have resulted in the same type erasure problem as before). As a result, we are made to choose which List methods to expose, thus creating a List abstraction, which provides an opportunity to exercise our object-oriented muscles.

Type erasure is an impetus for writing better code if you allow it to be. This pattern isn’t just for Java developers, it’s a good pattern in any language. So, the next time you encounter a limitation in a programming language, instead of complaining about it, just work around it and you may find a better solution than you would have had if the limitation wasn’t there¹.

¹ See my post Inheritance With One Hand Tied Behind Your Back for another example of a cool solution that was found by working around a programming language limitation.