ArrayFactory SAM type / toArray

[Raab, Donald]

Fair enough.  So what did your prototype code tell you?  Does it feel worthwhile going with this approach with the primitive array wrinkle (int.class returns Integer[] right?) or going the factory approach?

> -----Original Message-----
> From: Brian Goetz [mailto:brian.goetz at oracle.com]
> Sent: Thursday, November 08, 2012 11:54 AM
> To: Raab, Donald [Tech]
> Cc: lambda-libs-spec-experts at openjdk.java.net
> Subject: Re: ArrayFactory SAM type / toArray
> 
> But having them return Object undermines much of the point of adding
> these methods in the first place -- right now, we have
> 
>    Object[] toArray
> 
> and this forces unsafe casts.  We want Stream<T>.toArray() to return a
> T[].
> 
> We can still get to our goals for Collections/Streams with returning
> T[], but it could be creating some trouble for the future.
> 
> On 11/8/2012 11:46 AM, Raab, Donald wrote:
> > I was thinking about this.  If the methods returns Object, could we
> not just have an if-statement check if it was one of the primitive
> types and return a new int[] or new double[] in the method if they do
> instead of making the reflective call?
> >
> >> -----Original Message-----
> >> From: Brian Goetz [mailto:brian.goetz at oracle.com]
> >> Sent: Thursday, November 08, 2012 11:44 AM
> >> To: Raab, Donald [Tech]
> >> Cc: lambda-libs-spec-experts at openjdk.java.net
> >> Subject: Re: ArrayFactory SAM type / toArray
> >>
> >> On 9/19/2012 10:27 PM, Raab, Donald wrote:
> >>> Could we add the following methods to the Class class?
> >>>
> >>> T[] emptyArray()
> >>> T[] newArray(int size)
> >>
> >> I prototyped these, and they work fine for reference types but fall
> >> apart for primitive arrays.  There *is* a Class literal for
> >> int.class, but we can't make it return an int[] with this method.
> >> (This is one reason that Array.newInstance returns Object.)
> >> Performance testing would be needed to ensure they are competitive
> with alternatives.
> >