Primitives in Generics

Gernot Neppert mcnepp02 at
Thu Jul 8 11:08:59 PDT 2010

2010/7/8 Reinier Zwitserloot <reinier at>:
> Your idea is an intriguing one which would indeed drop the need for the
> JRockit boxing elimination optimization, though I don't think it can work.
> For example, the following 2 code samples would seem to be perfectly valid,
> but as far as I can tell the end result will be a NoSuchMethodError because
> the produced instance will not actually have the primitive version of the
> method. How will the compiler stop you from doing this, and, even if it
> does, how is a java programmer to know these snippets won't work?

> Snippet #1: new ArrayList<int>().add(10);

This would not compile according to my proposal. ArrayList does not
implement the int-based versions of the generic methods.
According to the proposal (paragraph 5.), the only way of implementing
a non-abstract class for a primitive-typed generic baseclass or
interface would be to supply all primitive-typed functions manually.
The compiler would generate the necessary bridge methods as
'synthetic' methods.
This means that you could not do this:

public class IntList extends AbstractList<int>
   public int get(int index)
// efficient int-based implementation

because the method public Integer get(int index) has already been
defined explicitly in AbstractList and you could not overload it
differing in return type only. But the compiler can - thererfore you'd
have to do:

public class IntList implements List<int>
   public boolean add(int element)
// efficient int-based implementation

in which case the compiler would generate the synthetic method Integer
get(int index).
A little more work to do, but asmall price to pay, I'd say!

More information about the lambda-dev mailing list