On 2013-11-27, at 6:53 AM, Peter Levart <peter.lev...@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
