ArrayFactory SAM type (original) (raw)

Raab, Donald Donald.Raab at gs.com
Thu Nov 8 09:02:35 PST 2012

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

More information about the lambda-libs-spec-observers mailing list