RFR(s): 8060192: Add default method Collection.toArray(generator)

Peter Levart peter.levart at gmail.com
Sun Jun 17 09:44:10 UTC 2018



On 06/17/18 10:50, Peter Levart wrote:
> The argument about using (and re-using) a method so that its method 
> reference can be passed to the toArray method without any unchecked 
> casts is equally true for any of the 3 alternatives shown - the method 
> itself might need unchecked casts, but its usage not:
>
> static List<String>[] array(int len)
> static Class<List<String>> elementType()
> static Class<List<String>[]> arrayType()

For that purpose, I would rather get rid of the need to create a method 
at all.

It might have been the case in the past when Java generics were 
introduced, that class literals like List<String>.class  would just 
confuse users, because most aspects of such type token would be erased 
and there were fears that enabling them might limit options for reified 
generics in the future. But long years have passed and java programmers 
have generally become acquainted with Java generics and erasure to the 
point where it doesn't confuse them any more, while reifying Java 
generics has been explored further in Valhalla to the point where it has 
become obvious that erasure of reference types is here to stay.

Java could enable use of class literals like List<String>.class without 
fear that such literals would make users write buggy code or that such 
uses would limit options for Java in the future. Quite the contrary, 
they would enable users to write type-safer code than what they can 
write today. In the light of future Java  (valhalla specialized 
generics), where such class literals make even more sense, enabling 
generic class literals could be viewed as a stepping stone that has some 
purpose in the short term too.

So what do you think?

Regards, Peter



More information about the core-libs-dev mailing list