JDK-5101892 : (reflect) retrofit Array.newInstance by using generics
  • Type: Enhancement
  • Component: core-libs
  • Sub-Component: java.lang:reflect
  • Affected Version: 5.0
  • Priority: P4
  • Status: Closed
  • Resolution: Won't Fix
  • OS: linux,windows_xp
  • CPU: generic,x86
  • Submitted: 2004-09-14
  • Updated: 2022-08-09
  • Resolved: 2004-09-15
Related Reports
Duplicate :  
Relates :  
Relates :  
Description
I think the following signature:

    public static <T> T[] Array.newInstance(Class<T> componentType, int length)

is more type safe than the current one:

    public static Object Array.newInstance(Class<?> componentType, int length)

Is there any reason we can't do this?
###@###.### 2004-09-14

Comments
EVALUATION It is not possible to preserve binary compatibility with older applications if Array.newInstance was retrofitted. Old class files will contain a reference to the method: java/lang/reflect/Array.newInstance:(Ljava/lang/Class;I)Ljava/lang/Object; Whereas the suggested retrofitted method would look like: java/lang/reflect/Array.newInstance:(Ljava/lang/Class;I)[Ljava/lang/Object; Notice the slightly different return type, the latter has an [ indicating an array. ###@###.### 2004-09-15 It is worth noting there are analagous situations where a method with a more precise return type can be retrofitted. If class C implements a method from an interface, say S m(), in Tiger, C could be changed to have an m method return a T where T is a subtype of S. When this sort of covariant return occurs, the class file for C has two m methods: S m() T m() At the vm level this is fine although it is not legal in source code. Since both methods are present in some sense, old binary clients can still invoke S m() but new source clients can benefit from T m(). However, none of this works for static methods. ###@###.### 2004-09-15
15-09-2004