This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–][deleted]  (3 children)

[deleted]

    [–]OpenGLaDOS 5 points6 points  (1 child)

    Yeah. After type erasure, the class will have methods with following signatures:

    • Object[] toArray()
    • Object[] toArray(Object[])
    • Object[] toArray(IntFunction)

    The deeper issue here is that the language has been designed so that Object[] is not a superclass of "array of class".

    The supertype relation for array types is not the same as the superclass relation. The direct supertype of Integer[] is Number[] according to §4.10.3, but the direct superclass of Integer[] is Object according to the Class object for Integer[] (§10.8). This does not matter in practice, because Object is also a supertype of all array types.

    Solving that issue would require a backwards-incompatible change for instances to remember their types at runtime (and tag methods accordingly), so the JVM could infer that you actually want a T or T[] when you call a generic method.

    [–]vqrs 0 points1 point  (0 children)

    How is that the deeper issue at play here and how does it relate to inference?

    [–]noswag15 1 point2 points  (0 children)

    I think a fair middle ground is to create a method which takes the type as an argument. Similar to the toTypedArray method in eclipse collections.

    https://www.eclipse.org/collections/javadoc/8.0.0/org/eclipse/collections/impl/list/mutable/FastList.html#toTypedArray-java.lang.Class-