RFR (S + L test) : 8016839 : JSR292: AME instead of IAE when calling a method

[Peter Levart]

On 11/27/2013 02:40 PM, David Chase wrote:
> On 2013-11-27, at 6:53 AM, Peter Levart <peter.levart at gmail.com> wrote:
>> Ah, I have misunderstood the back-porting issue. It was not about not having new class but about which existing class to use as a host that might not exist in older version of platform...
>>
>> Sorry for noise.
> Noise is okay.  This fix was a PITA, init order can hide surprises, and I don't mind going over the details.
>
> As to the activation of the code in question, practically never, except in tests or when bozo-bytecode-generators (a remark I resemble) are making mistakes.  The "initialize" of the throwIAE method is deferred until loading of a class that performs an illegal-access-override of an interface method -- e.g., interface I { int m(); } class C implements I { private int m(); } so even that requires an inconsistent set of classes, which is
> unlikely in any normal initialization.
>
> Longer-term/hoped-for plan is to create a custom throwIAE method each time this happens so that an informative error message can be included -- "C.m() overrides I.m() but is private" (or protected, or package-inaccessible) -- but that is tricky because we don't have a good place to put the method; by the time we learn this about class C, we have rewritten its constant pool and it is difficult to add more, and the constant pool cache is fragile-yet-critical-to-interpreter-performance.  So for now, I did this.
>
> I did test it as much as I could figure out how, including running the regression test in Netbeans and poking around, and also running it under jdb on some embedded platforms and trying to think of commands that might trigger embarrassing failures.
>
> The push is in the pipeline, but if you have other tests you can suggest, it is not too late to pull the emergency stop (in particular, I am gatekeeper for hs-comp this month, so I can put off the next turn of the crank till the last moment).
>
> David
>

Your and David Holmes' answers have pretty much silenced me. I can't 
think of any more troubles...

About creating an informative error message: is there a way to 
dynamically dig-out from the VM, while executing the single system-wide 
throwIAE method, the symbolic invocation attributes of a call-site 
together with the target object in case of instance method invocation? 
 From that data it could be possible to re-compute the context in 
question, I assume...

Regards, Peter