Transparency

[Nathan Bryant]

John,

If you mean what I think you mean, that seems to result in a generics that is useful only for interface definition. Either it's not possible to write:

foo = new ArrayList<int>()

Or doing so results in autoboxing to Integer, unbeknownst to the user, which is a serious violation of the principle of least surprise.

One way around this is to add an annotation that declares that a type parameter "accepts primitives", but this would render a lot of existing interface definitions unable to work with the scheme, rendering them nearly as obsolete as adding function types to the language would do.

Either way, adding combinators to the standard library during Java7 will force the choice of either SAMs or function types. If SAMs are the choice, and are implemented without the abovementioned annotation, it might have to be added later. If it's added later, and "accepts primitives" is to mean "reified", then that's most likely a binary incompatible change.

-----Original Message-----
From: John Nilsson [mailto:john at milsson.nu] 
Sent: Tuesday, July 13, 2010 5:59 PM
To: Nathan Bryant
Cc: Mark Thornton; lambda-dev at openjdk.java.net
Subject: Re: Transparency

On Tue, Jul 13, 2010 at 11:08 PM, Nathan Bryant
<nathan.bryant at linkshare.com> wrote:
>        void set(int i, T t) { arr[i] = t; } // Either causes autoboxing
> unbeknownst to the sorry fool who wrote new Foo<int>, or becomes illegal

How about just erasing T[] to Object and let API-developers worry
about picking an array implementation?

BR,
John