Primitives in Generics

[Gernot Neppert]

2010/7/8 Reinier Zwitserloot <reinier at zwitserloot.com>:
> 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!