I read a tweet today that said:
It's funny when Java users complain about type erasure, which is the only thing Java got right, while ignoring all the things it got wrong.
Thus my question is:
Are there benefits from Java's type erasure? What are the technical or programming style benefits it (possibly) offers other than the JVM implementations preference for backwards compatibility and runtime performance?
A lot of the answers thus far are overly concerned with the Twitter user. It's helpful to keep focused on the messages and not the messenger. There is a fairly consistent message with even just the excerpts mentioned thus far:
It's funny when Java users complain about type erasure, which is the only thing Java got right, while ignoring all the things it got wrong.
I get huge benefits (e.g. parametricity) and nil cost (alleged cost is a limit of imagination).
new T is a broken program. It is isomorphic to the claim "all propositions are true." I am not big into this.
These tweets reflect a perspective that is not interested in whether we can make the machine do something, but more whether we can reason that the machine will do something we actually want. Good reasoning is a proof. Proofs can be specified in formal notation or something less formal. Regardless of the specification language, they must be clear and rigorous. Informal specifications are not impossible to structure correctly, but are often flawed in practical programming. We end up with remediations like automated and exploratory tests to make up for the problems we have with informal reasoning. This is not to say that testing is intrinsically a bad idea, but the quoted Twitter user is suggesting that there is a much better way.
So our goal is to have correct programs that we can reason about clearly and rigorously in a way that corresponds with how the machine will actually execute the program. This, though, is not the only goal. We also want our logic to have a degree of expressivity. For example, there's only so much we can express with propositional logic. It's nice to have universal (∀) and existential (∃) quantification from something like first-order logic.
These goals can be very nicely addressed by type systems. This is especially clear because of the Curry-Howard correspondence. This correspondence is often expressed with the following analogy: types are to programs as theorems are to proofs.
This correspondence is somewhat profound. We can take logical expressions, and translate them through the correspondence to types. Then if we have a program with the same type signature that compiles, we have proven that the logical expression is universally true (a tautology). This is because the correspondence is two-way. The transformation between the type/program and the theorem/proof worlds are mechanical, and can in many cases be automated.
Curry-Howard plays nicely into what we'd like to do with specifications for a program.
Even with an understanding of Curry-Howard, some people find it easy to dismiss the value of a type system, when it
Regarding the first point, perhaps IDEs make Java's type system easy enough to work with (that's highly subjective).
Regarding the second point, Java happens to almost correspond to a first-order logic. Generics give use the type system equivalent of universal quantification. Unfortunately, wildcards only give us a small fraction of existential quantification. But universal quantification is pretty good start. It's nice to be able to say that functions for List<A> work universally for all possible lists because A is completely unconstrained. This leads to what the Twitter user is talking about with respect to "parametricity."
An often-cited paper about parametricity is Philip Wadler's Theorems for free!. What's interesting about this paper is that from just the type signature alone, we can prove some very interesting invariants. If we were to write automated tests for these invariants we would be very much wasting our time. For example, for List<A>, from the type signature alone for flatten
<A> List<A> flatten(List<List<A>> nestedLists);
we can reason that
flatten(nestedList.map(l -> l.map(any_function)))
≡ flatten(nestList).map(any_function)
That's a simple example, and you can probably reason about it informally, but it's even nicer when we get such proofs formally for free from the type system and checked by the compiler.
From the perspective of language implementation, Java's generics (which correspond to universal types) play very heavily into the parametricity used to get proofs about what our programs do. This gets to the third problem mentioned. All these gains of proof and correctness require a sound type system implemented without defects. Java definitely has some language features that allow us to shatter our reasoning. These include but are not limited to:
Non-erased generics are in many ways related to reflection. Without erasure there's runtime information that's carried with the implementation that we can use to design our algorithms. What this means is that statically, when we reason about programs, we don't have the full picture. Reflection severely threatens the correctness of any proofs we reason about statically. It's no coincidence reflection also leads to a variety of tricky defects.
So what are ways that non-erased generics might be "useful?" Let's consider the usage mentioned in the tweet:
<T> T broken { return new T(); }
What happens if T doesn't have a no-arg constructor? In some languages what you get is null. Or perhaps you skip the null value and go straight to raising an exception (which null values seem to lead to anyway). Because our language is Turing complete, it's impossible to reason about which calls to broken will involve "safe" types with no-arg constructors and which ones won't. We've lost the certainty that our program works universally.
So if we want to reason about our programs, we're strongly advised to not employ language features that strongly threaten our reasoning. Once we do that, then why not just drop the types at runtime? They're not needed. We can get some efficiency and simplicity with the satisfaction that no casts will fail or that methods might be missing upon invocation.
Erasing encourages reasoning.
Types are a construct used for writing programs in a manner that allows the compiler to check the correctness of a program. A type is a proposition on a value - the compiler verifies that this proposition is true.
During the execution of a program, there should be no need for type information - this has already been verified by the compiler. The compiler should be free to discard this information in order to perform optimisations on the code - make it run faster, generate a smaller binary etc. Erasure of type parameters facilitates this.
Java breaks static typing by allowing type information to be queried at runtime - reflection, instanceof etc. This allows you to construct programs that cannot be statically verified - they bypass the type system. It also misses opportunities for static optimisation.
The fact that type parameters are erased prevents some instances of these incorrect programs to be constructed, however, more incorrect programs would be disallowed if more type information was erased and the reflection and instanceof facilities were removed.
Erasure is important for upholding the property of "parametricity" of a data type. Say I have a type "List" parameterised over component type T. i.e. List<T>. That type is a proposition that this List type works identically for any type T. The fact that T is an abstract, unbounded type parameter means that we know nothing about this type, therefore are prevented from doing anything special for special cases of T.
e.g. say I have a List xs = asList("3"). I add an element: xs.add("q"). I end up with ["3","q"]. Since this is parametric, I can assume that List xs = asList(7); xs.add(8) ends up with [7,8] I know from the type that it doesn't do one thing for String and one thing for Int.
Furthermore, I know that the List.add function can not invent values of T out of thin air. I know that if my asList("3") has a "7" added to it, the only possible answers would be constructed out of the values "3" and "7". There is no possibility of a "2" or "z" being added to the list because the function would be unable to construct it. Neither of these other values would be sensible to add, and parametricity prevents these incorrect programs from being constructed.
Basically, erasure prevents some means of violating parametricity, thus eliminating possibilities of incorrect programs, which is the goal of static typing.
(Although I already wrote an answer here, revisiting this question two years later I realize there is another, completely different way of answering it, so I'm leaving the previous answer intact and adding this one.)
It is highly arguable whether the process done on Java Generics deserves the name "type erasure". Since generic types are not erased but replaced with their raw counterparts, a better choice seems to be "type mutilation".
The quintessential feature of type erasure in its commonly understood sense is forcing the runtime to stay within the boundaries of the static type system by making it "blind" to the structure of the data it accesses. This gives full power to the compiler and allows it to prove theorems based on static types alone. It also helps the programmer by constraining the code's degrees of freedom, giving more power to simple reasoning.
Java's type erasure does not achieve that—it cripples the compiler, like in this example:
void doStuff(List<Integer> collection) {
}
void doStuff(List<String> collection) // ERROR: a method cannot have
// overloads which only differ in type parameters
(The above two declarations collapse into the same method signature after erasure.)
On the flip side, the runtime can still inspect the type of an object and reason about it, but since its insight into the true type is crippled by erasure, static type violations are trivial to achieve and hard to prevent.
To make things even more convoluted, the original and erased type signatures co-exist and are considered in parallel during compilation. This is because the whole process is not about removing type information from the runtime, but about shoehorning a generic type system into a legacy raw type system to maintain backwards compatibility. This gem is a classic example:
public static <T extends Object & Comparable<? super T>> T max(Collection<? extends T> coll)
(The redundant extends Object had to be added to preserve backward compatibility of the erased signature.)
Now, with that in mind, let us revisit the quote:
It's funny when Java users complain about type erasure, which is the only thing Java got right
What exactly did Java get right? Is it the word itself, regardless of meaning? For contrast take a look at the humble int type: no runtime type check is ever performed, or even possible, and the execution is always perfectly type-safe. That's what type erasure looks like when done right: you don't even know it's there.
A subsequent post by the same user in the same conversation:
new T is a broken program. It is isomorphic to the claim "all propositions are true." I am not big into this.
(This was in response to a statement by another user, namely that "it seems in some situations 'new T' would be better", the idea being that new T() is impossible due to type erasure. (This is debatable — even if T were available at runtime, it could be an abstract class or interface, or it could be Void, or it could lack a no-arg constructor, or its no-arg constructor could be private (e.g., because it's supposed to be a singleton class), or its no-arg constructor could specify a checked exception that the generic method does not catch or specify — but that was the premise. Regardless, it's true that without erasure you could at least write T.class.newInstance(), which handles those issues.))
This view, that types are isomorphic to propositions, suggests that the user has a background in formal type theory. (S)he very likely does not like "dynamic types" or "runtime-types" and would prefer a Java without downcasts and instanceof and reflection and so on. (Think of a language like Standard ML, which has a very rich (static) type system and whose dynamic semantics do not depend on any type information whatsoever.)
It's worth keeping in mind, by the way, that the user is trolling: while (s)he likely sincerely prefers (statically) typed languages, (s)he is not sincerely trying to persuade others of that view. Rather, the main purpose of the original tweet was to mock those who disagree, and after some of those disagree-ers chimed in, the user posted follow-up tweets such as "the reason java has type erasure is that Wadler et al know what they are doing, unlike users of java". Unfortunately, this makes it hard to find out what (s)he's actually thinking; but fortunately, it also likely means that it's not very important to do so. People with actual depth to their views don't generally resort to trolls that are quite this content-free.
The one thing I don't see considered here at all is that OOP's runtime polymorphism is fundamentally dependent on the reification of types at runtime. When a language whose backbone is held in place by refied types introduces a major extension to its type system and bases it on type erasure, cognitive dissonance is the inevitable outcome. This is precisely what happened to the Java community; it is why type erasure has attracted so much controversy, and ultimately why there are plans to undo it in a future release of Java. Finding something funny in that complaint of Java users betrays either an honest misunderstanding of the spirit of Java, or a consciously deprecating joke.
The claim "erasure is the only thing Java got right" implies the claim that "all languages based on dynamic dispatch against the runtime type of function argument are fundamentally flawed". Although certainly a legitimate claim on its own, and one which can even be considered as valid criticism of all OOP languages including Java, it cannot lodge itself as a pivotal point from which to evaluate and criticise features within the context of Java, where runtime polymorphism is axiomatic.
In summary, while one may validly state "type erasure is the way to go in language design", positions supporting type erasure within Java are misplaced simply because it is much, much too late for that and had already been so even at the historical moment when Oak was embraced by Sun and renamed to Java.
As to whether static typing itself is the proper direction in the design of programming languages, this fits into a much wider philosophical context of what we think constitutes the activity of programming. One school of thought, clearly deriving from the classical tradition of mathematics, sees programs as instances of one mathematical concept or other (propositions, functions, etc.), but there is an entirely different class of approaches, which see programming as a way to talk to the machine and explain what we want from it. In this view the program is a dynamic, organically growing entity, a dramatic opposite of the carefully erected aedifice of a statically typed program.
It would seem natural to regard the dynamic languages as being a step in that direction: the consistency of the program emerges from the bottom up, with no a priori constrants which would impose it in a top-down manner. This paradigm can be seen as a step towards modeling the process whereby we, the humans, become what we are through development and learning.
One good thing is that there was no need to change JVM when generics were introduced. Java implements generics at compiler level only.
The reason type erasure is a good thing is that the things it makes impossible are harmful. Preventing the inspection of type arguments at runtime makes understanding and reasoning about programs easier.
An observation that I found somewhat counter-intuitive is that when function signatures are more generic, they become easier to understand. This is because the number of possible implementations is reduced. Consider a method with this signature, which we somehow know has no side effects:
public List<Integer> XXX(final List<Integer> l);
What are the possible implementations of this function? Very many. You can tell very little about what this function does. It could be reversing the input list. It could be pairing ints together, summing them and returning a list half the size. There are many other possibilities that could be imagined. Now consider:
public <T> List<T> XXX(final List<T> l);
How many implementations of this function are there? Since the implementation cannot know the type of the elements, a huge number of implementations can now be excluded: elements cannot be combined, or added to the list or filtered out, et al. We are limited to things like: identity (no change to the list), dropping elements, or reversing the list. This function is easier to reason about based on its signature alone.
Except… in Java you can always cheat the type system. Because the implementation of that generic method can use stuff like instanceof checks and/or casts to arbitrary types, our reasoning based on the type signature can be easily rendered useless. The function could inspect the type of the elements and do any number of things based on the result. If these runtime hacks are allowed, parameterised method signatures become much less useful to us.
If Java did not have type erasure (that is, type arguments were reified at runtime) then this would simply allow more reasoning-impairing shenanigans of this kind. In the above example, the implementation can only violate the expectations set by the type signature if the list has at least one element; but if T was reified, it could do so even if the list were empty. Reified types would just increase the (already very many) possibilities for impeding our understanding of the code.
Type erasure makes the language less "powerful". But some forms of "power" are actually harmful.
This is not a direct answer (OP asked "what are the benefits", I am replying "what are the cons")
Compared to C# type system, Java type erasure is a real pain for two raesons
In C# you can implement both IEnumerable<T1> and IEnumerable<T2> safely, especially if the two types do not share a common ancestor (i.e. their ancestor is Object).
Practical example: in Spring Framework, you can't implement ApplicationListener<? extends ApplicationEvent> multiple times. If you need different behaviours based on T you need to test instanceof
(and you need a reference to Class to do that)
As others commented, doing the equivalent of new T() can only be done via reflection, only by invoking an instance of Class<T>, making sure about the parameters required by the constructor. C# allows you to do new T() only if you constrain T to parameterless constructor. If T does not respect that constraint, a compile error is raised.
In Java, you will often be forced to write methods that look like the following
public <T> T create(....params, Class<T> classOfT)
{
... whatever you do
... you will end up
T = classOfT.newInstance();
... or more advanced reflection
Constructor<T> parameterizedConstructorThatYouKnowAbout = classOfT.getConstructor(...,...);
}
The drawbacks in the above code are:
ReflectiveOperationException is thrown at runtimeIf I was the author of C#, I would have introduced the ability to specify one or more constructor constraints that are easy to verify at compile time (so I can require for example a constructor with string,string params). But the last one is speculation
An additional point none of the other answers seem to have considered: if you really need generics with run-time typing, you can implement it yourself like this:
public class GenericClass<T>
{
private Class<T> targetClass;
public GenericClass(Class<T> targetClass)
{
this.targetClass = targetClass;
}
This class is then able to do all the things that would be achievable by default if Java did not use erasure: it can allocate new Ts (assuming T has a constructor that matches the pattern it expects to use), or arrays of Ts, it can dynamically test at run time if a particular object is a T and change behaviour depending on that, and so on.
For example:
public T newT () {
try {
return targetClass.newInstance();
} catch(/* I forget which exceptions can be thrown here */) { ... }
}
private T value;
/** @throws ClassCastException if object is not a T */
public void setValueFromObject (Object object) {
value = targetClass.cast(object);
}
}
avoids c++-like code bloat because the same code is used for multiple types; however, type erasure requires virtual dispatch whereas the c++-code-bloat approach can do non-virtually dispatched generics
Most answers are more concerned about programming philosophy than the actual technical details.
And although this question is more than 5 years old, the question still lingers: Why is type erasure desireable from a technical point of view? In the end, the answer is rather simple (on a higher level): https://en.wikipedia.org/wiki/Type_erasure
C++ templates don't exist at runtime. The compiler emits a fully optimized version for each invocation, meaning the execution doesn't depend on type information. But how does a JIT deal with different versions of the same function? Wouldn't it be better to just have one function? Wouldn't want the JIT to have to optimize all the different versions of it. Well, but then what about type safety? Guess that has to go out of the window.
But wait a second: How does .NET do it? Reflection! This way they only have to optimize one function and also get runtime type information. And that is why .NET generics used to be slower (though they have gotten much better). I am not arguing that that isn't convenient! But it is expensive and shouldn't be used when it isn't absolutely necessary (it isn't considered expensive in dynamically typed languages because the compiler / interpreter relies on reflection anyway).
This way generic programming with type erasure is close to zero overhead (some runtime checks / casts are still required): https://docs.oracle.com/javase/tutorial/java/generics/erasure.html
