[10] RFR (S): 8196022: java.lang.VerifyError is thrown instead of java.lang.IllegalAccessError

[Paul Sandoz]

> On Jan 26, 2018, at 10:34 AM, Vladimir Ivanov <vladimir.x.ivanov at oracle.com> wrote:
> 
> Thanks for review, Paul.
> 
>> This is quite a subtle and confusing area. I believe you have the mapping correct with a cleaner correspondence between reflective exceptions and errors. +1
> 
> FTR I don't insist on pushing it into 10. The missing checks for corner cases in SystemDictionary::link_method_handle_constant() is covered later during down call, so the only risk is that JDK-8188145 [1] fix won't work for those corner cases, which is very low.
> 
> So, if anybody doesn't feel comfortable pushing it into 10, I'm fine with delaying the fix till 11.
> 

Given it's such a corner case 11 seems ok, others may differ since it is marked as a P1 bug, but i am unsure why, seems more of a P4 to me which would not justify going into 10.


>> I am having a hard time understanding how a ClassNotFoundException can originate when resolving a member name from symbolic information (and when resolving in Java via a lookup Class objects are required).
>> Perhaps it’s due to logic in SystemDictionary::handle_resolution_exception:
> 
> Yes, exactly. I had hard time proving SystemDictionary::handle_resolution_exception isn't called with throw_error = false during method/field resolution, so decided to play it safe and cover it on JVM side to avoid dealing with that on JDK side.
> 

Ok.

Paul.