JDK-4301875 : (reflect) Class.getConstructor(Class[]) should allow subclasses
  • Type: Enhancement
  • Component: core-libs
  • Sub-Component: java.lang:reflect
  • Affected Version: 1.2.2
  • Priority: P4
  • Status: Closed
  • Resolution: Duplicate
  • OS: windows_98
  • CPU: x86
  • Submitted: 1999-12-26
  • Updated: 2012-09-28
  • Resolved: 2002-03-13
Related Reports
Duplicate :  
JDK-4287725 - (reflect) Allow subclasses of stated argument types in Class.getMethod()
Relates :  
JDK-4651775 - (reflect spec) Class.get(Declared)+{Method,Constructor} does not define "match"
Description

Name: krT82822			Date: 12/26/99


An earlier bug report (filed as an Ease of Use issue) noted:

>Class.getConstructor(Class[]) fails to find a constructor (throws
>NoSuchMethodException) if an arg type is a subclass of the actual arg type.
>
>EX: SomeClass(Person who) // <-- constructor
>is not found if Class.getConstructor() is given a Class[] = {PersonSubClass}

getConstructor should return the constructor that will accept the argument types
you pass it, even if the types are not EXACT matches (i.e., even if they're
subclasses of the types expected)

------------------------------

(see also 4017835)
(Review ID: 99337) 
======================================================================
Comments
EVALUATION We cannot make this change for compatibility reaons. Furthermore, we would expect that getConstructor should behave analogously to getDeclaredMethod, which also requires an exact match, thus it does not make sense to change one without changing the other. It would be possible to add an additional suite of methods that differed only in the way in which the argument types were matched, however. There are certainly cases where we might want to apply at runtime during reflection the same overload-resolution algorithm used statically by the compiler, i.e., in a debugger. It is not difficult to implement this functionality with the existing API, however, so the case for adding this functionality to core reflection is weak. william.maddox@Eng 2000-01-03
03-01-2000