On 21/04/2017 11:04, Andrew Dinn wrote:
Being a good OpenJDK citizen I have attempted to make my agent use
lookups in jdk9 in place of using reflection. This is mostly working
fine. However, I have run across a rather arbitrary limitation (not just
my conclusion -- the jdk source code acknowledges it as such) and am
wondering whether there will be any chance of remedying it before (or
after) jdk9 release.
The check in checkUnprivilegedlookupClass isn't new, I think it's a
defense-in-depth check that goes back to JDK 7 to catch usages of full
power lookups in fully privileged code. There was recent discussion on
core-libs-dev about this, prompted by work that Paul Sandoz was doing to
retrofit LockSupport and TLR to use privateLookupIn. My recollection is
that he relaxed the check to allow the target class be Thread or a class
in j.u.concurrent and the more general question on whether this check is
needed was kicked down the road. I'm sure John Rose or Paul will jump in
on this thread.
BTW: None of the modules defined to the boot loader open packages so I
wouldn't expect too many people will run into this. You run into in the
example because java.net.HttpURLConnection is in java.base and defined
to the boot loader. I guess another possible scenario would be someone
opening a package in a core module with `--add-opens` and the raiding
party uses privateLookupIn.
-Alan.
