Is this a first step to fixing the compiler error where the JLS says the (2nd) expression in an assert statement is converted to String and a new AssertionError is constructed with that STRING as the argument, and that AssertionError is thrown? (my paraphrase)
http://java.sun.com/docs/books/jls/third_edition/html/statements.html#14.10 BUT assert false : new Throwable(); has evidence to suggest that this (JLS spec) is not currently the case, since the AssertionError thrown has a cause, and therefore the Throwable was not converted to a String before being passed to the AssertionError constructor. You can get away with having the AssertionError constructor do the conversion in all other cases (which reduces the amount of bytecode emitted for each assert statement), but this currently does not work for a Throwable. So it might be better for the 1st argument of the new method to be Object, and having almost the same semantics as the current single Object arg constructor - except it would NOT treat the first arg as the cause when it is a Throwable. This way the assert statements could for (other than primitives) be compiled to call the 2 arg constructor with a null value for second arg and thus become indistinguishable (other than bytecode inspection) from something that did exactly as the JLS says. yeah - call me pedantic if you want :-) Bruce Joe Darcy wrote:
Hello. Please review my fix for 6935997 "Please add a nested throwable constructor to AssertionError" http://cr.openjdk.java.net/~darcy/6935997.0/ Thanks, -Joe
