I think our implementation of java.lang.Class's newinstance() is incorrect. Specifically, Class.newinstance() uses reflection to invoke a class's zero-argument constructor and then, if it catches an InvocationTargetException, unwraps that exception, throwing whatever exception was originally thrown by the constructor.
The exact code we currently have is: catch (InvocationTargetException e) { VMClass.throwException(e.getTargetException()); throw (InternalError) new InternalError ("VMClass.throwException returned").initCause(e); } This has the effect that Class.newinstance() can throw any exception at all, without any warning to the caller. * This is at variance with the (different) interpretation specified in the Javadoc comment at the head of Class.newInstance(): * @throws InstantiationException if there is not a no-arg constructor * for this class, including interfaces, abstract classes, arrays, * primitive types, and void; or if an exception occurred during ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ * the constructor ^^^^^^^^^^^^^^ The patch itself is trivial, but I want to check that others share my interpretation; this seems so wrong that I wonder whether I'm missing something. I would change the code to read something like: catch (InvocationTargetException e) { Throwable t = e.getTargetException(); InstantiationException ie = new InstantiationException("Trouble calling newinstance()" + " on the class " + toString()); ie.setCause(t); throw ie; } One effect of this mis-implementation is the existence of a VM-specific method that does not need to exist: VMClass.throwException(Throwable). Its stub reads: /** * Throw a checked exception without declaring it. */ static native void throwException(Throwable t); This method is only used by our java.lang.Class.newInstance(). This method can go away in future releases of Classpath. In the mean time, I have been implementing VMClass for Jikes RVM, so that we can stop using our own version of java.lang.Class. Until the next release of Classpath eliminates the need for VMClass.throwException(), it seems to me that the best solution is to make VMClass.throwException() wrap the exception it's given with an InstantiationException and throw that. I am looking for feedback on this, especially including any alternative interpretations of how Class.newInstance() should handle it if the target class's zero-arg constructor throws an exception. Thanks, --Steve Augart -- Steven Augart Jikes RVM, a free, open source, Virtual Machine: http://oss.software.ibm.com/jikesrvm _______________________________________________ Classpath mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/classpath