It's not too late for access control

[John Rose]

On Jul 12, 2016, at 9:38 AM, Andrew Dinn <adinn at redhat.com> wrote:
> 
> I'm not sure how AOT compiled code is supposed to protect itself against
> the potential consequences of my agent tweaking accessibility in this
> way. Would it be not require -- at the least -- wholesale deoptimization
> of compiled methods in the module to which the package is exported? How
> would one arrange for JITted code to trap out and invalidate any
> speculative optimizations that might be invalidated by this incremental
> export?

Either wholesale de-opt, or a fast-fail error when the injection is attempted.
(It's another example of the tug-of-war between parties with different views on a class.)

Either outcome is bad enough that we need speed bumps to prevent people
from just cruising heedlessly into the failure zone.  By "speed bump" I mean
a need to assert extra-specific intention, and/or obtain an access right,
in order to increase the visibility of (or inject code into) a module that
has been consolidated into an AOT sub-assembly.  (N.B. I'm using these
terms in a general sense, not referring to any particular tech.)

BTW, if you contrive to inject a MethodHandles.Lookup donor into
a class, the donee can get everything (99.9%) the class can do by
materializing and calling appropriate method handles.  With a little
care (bind the MHs to static finals) you get identical performance.  
This is easier than spinning adapters and injecting those one by one.
Is that how you are doing your injection?

— John