> On 15 Apr 2016, at 09:33, Peter Levart <peter.lev...@gmail.com> wrote: > > Hi Paul, > > On 04/14/2016 04:40 PM, Paul Sandoz wrote: >> Hi Peter, >> >> You found that annoying restriction :-) at this point i think this is mostly >> redundant. >> >> This is something i planned to update and limit the restriction to code >> within j.l.invoke and sun.invoke packages. > > sun.invoke is explicitly allowed currently. >
Ah, yes i missed the “!”. >> >> I'll follow up with a patch soon to unblock, but feel free to beat me to it >> if you wish. > > I don't quite understand this restriction. Seems to be that it was written at > the time where the only classes loaded by bootstrap class loader were located > in packages java.** and sun.** (was that actually true at some point?) and > the restriction explicitly excludes classes in sun.invoke.** packages as > though they are the only trusted code to be able to obtain such lookup. Does > a Lookup with a lookup class loaded by the bootstrap class loader and > allowedModes == ALL_MODES possess any special privileges that a Lookup with a > lookup class loaded by the application class loader and allowedModes == > ALL_MODES doesn’t? > No as far as i know. The case i am most concerned more so about is usage within the Lookup.in method. I am inquiring off-list as to changes to checkUnprivilegedlookupClass. Paul.
