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
