Review request for 7198429: need checked categorization of caller-sensitive methods in the JDK
Alan Bateman
Alan.Bateman at oracle.com
Mon Apr 1 19:28:59 UTC 2013
On 27/03/2013 17:35, Mandy Chung wrote:
> This is the JDK change for JEP 176: JEP 176: Mechanical Checking of
> Caller-Sensitive Methods [1]. Christian has posted the webrev for the
> hotspot VM change a couple weeks ago [2].
>
> Webrev at:
> http://cr.openjdk.java.net/~mchung/jdk8/webrevs/7198429/webrev.00/
>
> While it touches many files, the fix is simple and straight-forward
> for review.
I went through the latest webrev.01 and this looks very good.
I guess I was initially surprised to see @CS on some of the
AccessController.doPrivileged methods as these usages aren't checked
(although they are caller sensitive).
Did you consider adding a constant, JVM_DEPTH (-1) or some name like
that, to jvm.h for the depth parameter?
I see Reflection.isCallerSensitive uses isExtClassLoader, we'll probably
have to re-visit this in the future.
Doug and Chris are on this list but might not have seen that this
updates AtomicXXXXFieldUpdaters. They need to be aware of this for
future merges.
On the tests, does GetCallerClassTest really need to check the stack
trace? It seems unnecessary.
One thing on the shell test (I read exchange about jtreg boot class path
support) is that it needs the GPL header.
I was surprised to see CallerSensitiveFinder in the webrev and I'm
curious how long it takes to run.
-Alan.
More information about the core-libs-dev
mailing list