Primitives in Generics

[Reinier Zwitserloot]

You didn't mention my second snippet, which is a shame, because I included
it because that's the one I'm confused about - how could you possibly write
a compiler that detects there's a problem there?

--Reinier Zwitserloot



On Thu, Jul 8, 2010 at 8:08 PM, Gernot Neppert <mcnepp02 at googlemail.com>wrote:

> 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!
>