Why don't Java Generics support primitive types?

Question

Why do generics in Java work with classes but not with primitive types?

For example, this works fine:

List<Integer> foo = new ArrayList<Integer>();

but this is not allowed:

List<int> bar = new ArrayList<int>();

Cypsela

int i=(int)new Object(); compiles just fine though. – Hillary

Answer 1

Generics in Java are an entirely compile-time construct - the compiler turns all generic uses into casts to the right type. This is to maintain backwards compatibility with previous JVM runtimes.

This:

List<ClassA> list = new ArrayList<ClassA>();
list.add(new ClassA());
ClassA a = list.get(0);

gets turned into (roughly):

List list = new ArrayList();
list.add(new ClassA());
ClassA a = (ClassA)list.get(0);

So, anything that is used as generics has to be convertable to Object (in this example get(0) returns an Object), and the primitive types aren't. So they can't be used in generics.

Japan

So is generics in Java implemented a bit like C++ templates? Can you get code bloat? – Caulk

@danyal: Nope - the same class implementation is used for all generic uses. It is all implemented using direct casts to/from the right types in the right places. – Japan

That last sentence is incorrect; C# has always supported co/contravariance on a per-type basis, exactly like Java. See the where keyword – Suppression

@DanyalAytekin - In fact, Java generics are NOT handled like C++ templates at all ... – Wrongdoer

Why can't the Java compiler also box the primitive type before it gets used? This should be possible right? – Indonesia

@Indonesia - It might be possible. But it would just be syntactic sugar. The real problem is that Java generics with boxed primitives is relatively expensive in both time and space compared with the C++ / C# model ... where the actual primitive type is used. – Wrongdoer

@Ced @vrvim nobody forbids you from using the wrapper types, e.g., List<Integer>. Java will box/unbox as appropriate, so no problem getting the numbers in and out. – Weed

@Weed what's that ? Streams ? IntStream, LongStream, DoubleStream. The issue is that java forbids to do List<int>, Stream<int> – Ofris

@Ofris I know. My point is that you can always use the wrapper types, though that will probably lead to problems elsewhere, as the accepted answer of #5199859 demonstrates. – Weed

@Weed yeah I know I can :) I stand by my ground that this is terrible design tho. Hopefully it'll get fixed in java 10 (or so I heard) and also higher order functions. Don't quote me on that tho. – Ofris

@Ofris fully agree on that it's bad design which endlessly hurts beginners ano professionals alike – Weed

Can't the compiler do templating like C compilers, generating the primitive method as an overload? Or are any new JVM-based languages already doing it? – Kelbee

The answer to the people who are insisting that this is "a bad design" is that it had to be that way. The alternative was breaking changes to the Java language which would have required Sun/Oracle's existing (paying) customers to review billions of lines of source code. That was not acceptable. (That was in 2004. The amount of code review in 2018 would be 2 or 3 orders of magnitude larger.) – Wrongdoer

And no it won't get fixed in some future version of Java because it would still be a massively breaking change. This would be like the Python 2 -> 3 upheaval. Enterprise (paying) customers wouldn't stand for it. (Read - your company's CIO ... the guy who has to find the human resources to do the work, and who decides which programming languages shall be used going forward.) – Wrongdoer

@StephenC: I'm surprised by your statement that supporting List<int> would require breaking changes. If there were a desire to implement it, why couldn't it be implemented using autoboxing/autounboxing and erasure? – Turkoman

@Turkoman - That sounds exactly like List<Integer> plus some syntactic sugar. It doesn't really solve anything. Performance would be the same as before. The performance overheads of boxing / unboxing, up to 24 bytes per int element (in an ArrayList) compared with 4 for an int[], extra GC overheads, etcetera. – Wrongdoer

@StephenC: Correct. I thought you were saying that this was impossible to do in a backward-compatible way, but I guess you were actually just saying that it wouldn't have the desired benefits if done in a backward-compatible way. OK. – Turkoman

Yea. A "solution" without the desired benefits of a solution is not a solution. In this case a "solution" is possible, but not a solution. But this is just repeating stuff that I said already; see my earlier comment to vrwim above. That is the context for my later comments. – Wrongdoer

@StephenC Never say never. Still, won’t come tomorrow… – Abducent

Answer 2

In Java, generics work the way that they do ... at least in part ... because they were added to the language a number of years after the language was designed¹. The language designers were constrained in their options for generics by having to come up with a design that was backwards compatible with the existing language and the Java class library.

Other programming languages (e.g. C++, C#, Ada) do allow primitive types to be used as parameter types for generics. But the flip side of doing this is that such languages' implementations of generics (or template types) typically entail generation of a distinct copy of the generic type for each type parameterization.

---

^{1 - The reason generics were not included in Java 1.0 was because of time pressure. They felt that they had to get the Java language released quickly to fill the new market opportunity presented by web browsers. James Gosling has stated that he would have liked to include generics if they had had the time. What the Java language would have looked like if this had happened is anyone's guess.}

Wrongdoer

Answer 3

In java generics are implemented by using "Type erasure" for backward compatibility. All generic types are converted to Object at runtime. for example,

public class Container<T> {

    private T data;

    public T getData() {
        return data;
    }
}

will be seen at runtime as,

public class Container {

    private Object data;

    public Object getData() {
        return data;
    }
}

compiler is responsible to provide proper cast to ensure type safety.

Container<Integer> val = new Container<Integer>();
Integer data = val.getData()

will become

Container val = new Container();
Integer data = (Integer) val.getData()

Now the question is why "Object" is chose as type at runtime?

Answer is Object is superclass of all objects and can represent any user defined object.

Since all primitives doesn't inherit from "Object" so we can't use it as a generic type.

FYI : Project Valhalla is trying to address above issue.

Feverous

Plus 1 for proper nomenclature. – Propagandize

Answer 4

As per Java Documentation, generic type variables can only be instantiated with reference types, not primitive types.

This is supposed to come in Java 10 under Project Valhalla.

In Brian Goetz paper on State of the Specialization

There is an excellent explanation about the reason for which generic were not supported for primitive. And, how it will be implemented in future releases of Java.

Java's current erased implementation which produces one class for all reference instantiations and no support for primitive instantiations. (This is a homogeneous translation, and the restriction that Java's generics can only range over reference types comes from the limitations of homogeneous translation with respect to the bytecode set of the JVM, which uses different bytecodes for operations on reference types vs primitive types.) However, erased generics in Java provide both behavioral parametricity (generic methods) and data parametricity (raw and wildcard instantiations of generic types.)

...

a homogeneous translation strategy was chosen, where generic type variables are erased to their bounds as they are incorporated into bytecode. This means that whether a class is generic or not, it still compiles to a single class, with the same name, and whose member signatures are the same. Type safety is verified at compile time, and runtime is unfettered by the generic type system. In turn, this imposed the restriction that generics could only work over reference types, since Object is the most general type available, and it does not extend to primitive types.

Selfreliance

Answer 5

The collections are defined to require a type which derives from java.lang.Object. The basetypes simply don't do that.

Smith

I think the question here is "why". Why do generics require Objects? The consensus appears to be that it's less of a design choice and more caving in to backward compatibility. In my eyes, if generics can't handle primitives, that's a functionality deficit. As it stands, everything involving primitives has to be written for each primitive: instead of Comparator<t,t>, we have Integer.compare(int a, int b), Byte.compare(byte a, byte b), etc. That's not a solution! – Firmin

Yeah generics over primitive types would is a must-have feature. Here is a link to a proposal for it openjdk.java.net/jeps/218 – Shamblin