Steven Augart wrote:
It is now the documented behaviour as of JDK 1.5.0rc1. (And it is
*really annoying* to implement in a VM written in Java, like
Jikes RVM).
A while ago it occurred to me that Thread.stop(Throwable) can also be
used to throw arbitrary exceptions (on the current thread).
Jeroen Frijters wrote:
Steven Augart wrote:
It is now the documented behaviour as of JDK 1.5.0rc1. (And it is
*really annoying* to implement in a VM written in Java, like
Jikes RVM).
A while ago it occurred to me that Thread.stop(Throwable) can also be
used to throw arbitrary exceptions (on
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
Steven Augart wrote:
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
Archie Cobbs wrote:
Steven Augart wrote:
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,
This is a well-known bug in the spec.. see
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4233093
Sun has yet to do anything about it.
And from all reports they won't. Class.newInstance is claimed to be working
as designed and we should use Constructor.newInstance if we want
David Holmes wrote:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4233093
Sun has yet to do anything about it.
And from all reports they won't. Class.newInstance is claimed to be working
as designed and we should use Constructor.newInstance if we want sensible
semantics.
I
7 matches
Mail list logo