webrev: http://cr.openjdk.java.net/~drchase/8026818/webrev.01/
bug: https://bugs.openjdk.java.net/browse/JDK-8026818 problem: The report describes a number of problems, cause by 3 separate bugs. The first is a dupe of https://bugs.openjdk.java.net/browse/JDK-8016839 . The second is a fault in the test itself, and a proposed patch is now attached to the bug. The third is caused by code in java.lang.invoke that converts an XXXError into an XXXException, which is sometimes passed on to client code as that exception, and other times (through other call chains) converted back to an XXXError. However and unfortunately, there is no such thing as an AbstractMethodException, and so it is mapped to IllegalAccessException; this is the current behavior. Through the other call chains the IAException is translated back to an error -- IllegalAccessError -- which is not what is specified. fix: The code in MethodHandleNatives already attempts to reuse the original Error when it matches the class of the one that would be thrown (to help avoid IllegalAccessError wraps IllegalAccessException wraps IllegalAccessError). In the case of IAException, a special check is added to see if the original Error was AbstractMethodError, and if it was, throws that instead. I originally considered mapping IAError to NoSuchMethodException and checking that NSMEx for cause=AMError, but that would change behavior for client code that had originally received IAException. It's not too weird to think that AMError should map to NSMException, but because of the change in behavior I decided not to do this. I think this is already reviewed by John Rose -- I pinged him in person, and we discussed the original and revised fix, as well as several others that seemed even less reasonable after a little reflection. testing: defmeth, A/B comparisons. ute, vm.quick.testlist, A/B comparisons. jtreg, jdk/lambda java/lang/invoke java/util/stream, A/B comparisons.
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
