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

[David Chase]

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