JDK-4047846 : (reflect) Constructor.newInstance doesn't check enclosing object for null
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.lang:reflect
  • Affected Version: 1.1
  • Priority: P4
  • Status: Closed
  • Resolution: Duplicate
  • OS: solaris_2.5.1
  • CPU: sparc
  • Submitted: 1997-04-26
  • Updated: 2025-07-29
  • Resolved: 2025-07-29
Related Reports
Duplicate :  
JDK-8164714 - Constructor.newInstance creates instance of inner class with null outer class
Description
Constructor.newInstance doesn't check the first parameter to see if it isn't null when used to construct an inner class, although the enclosing object should never *be* null.  It is better to catch this on creation than on first use.
Comments
Didn't know this has caught attention for so long - but after almost 28 years we finally fixed this from the javac side.
29-07-2025
PUBLIC COMMENTS Constructor.newInstance doesn't check the first parameter to see if it isn't null when used to construct an inner class, although the enclosing object should never *be* null. It is better to catch this on creation than on first use.
10-06-2004
EVALUATION This is a library problem. When the constructor is called from code generated by the compiler, the enclosing object is never null. If the compiler cannot verify that this is so at compile-time, a runtime check is generated during translation of the 'new' expression. It appears that the same check should be performed by 'Constructor.newInstance'. It does not make sense to push the check into the code for the constructor itself, as there are many cases where the compiler can verify statically that the enclosing object is non-null, such as in a cascade of 'new' expressions, e.g., (new Foo()).new Bar() . william.maddox@Eng 1997-10-22 A special case in Constructor.newInstance() to check that this is the Constructor of an inner class sounds ugly. In a way, I think this goes back to the "does reflection provide language-level or VM-level semantics?" question. Instead of hacking the current implementation to mimic language level semantics, it might be better to add: Contructor.newInstance(Object outer, Object[] initArgs) Better because it makes the programmer to think about the pointer to the enclosing scope -- this is no worse than the status quo which requires "outer" to be in initargs[0]. Since it is too late for API changes in 1.2, I am lowering the priority on this bug. anand.palaniswamy@Eng 1998-08-31 Such a check may "sound ugly", but it is necessary. Yes, a new call should have been provided in reflection for this, but it wasn't and all existing code written under 1.1 and 1.2 uses the existing newInstance(). So it should work properly, which means it should check inner class creation for null references. ken.arnold@East 1998-09-04
04-09-1998