Review request for 7198429: need checked categorization of caller-sensitive methods in the JDK (original) (raw)

Alan Bateman Alan.Bateman at oracle.com
Tue Apr 2 14:41:31 UTC 2013

On 02/04/2013 00:25, Mandy Chung wrote:

These few methods are the special case that their usage are not checked. This raises a good point how we could enforce the check and whether it's appropriate to check in JVMDoPrivileged. I will file a bug to follow up this separately if you are okay. Thanks.

On the tests, does GetCallerClassTest really need to check the stack trace? It seems unnecessary. The stack trace check tries to catch if InternalError is thrown for other reason. Such regression might be rare but I prefer to perform an appropriate check while the test can reliably run. Okay, my comment that mostly that this checking seem a bit over-the-top.

:

I was surprised to see CallerSensitiveFinder in the webrev and I'm curious how long it takes to run.

This is one discussion point I'd like to have. I was debating myself initially if this test should be enabled or not. What I found it takes 5-14 sec. Some sample timing on the jprt machines: linuxi586 jdklang took 14 mins and CallerSensitiveFinder took 8.5 sec macosxx64 jdklang took 20.5 mins and CallerSensitiveFinder took 14.5 sec solarisi586 jdklang took 15.5 mins and CallerSensitiveFinder took 10 sec windowsx64 jdklang took 16.5 mins and CallerSensitiveFinder took 10 sec We discussed tagging stress tests or long running tests so that they can be run on demand. I think this test would also be appropriate to be run in post-build hudson job, kind of tests. The duration is a lot less than I expected and I don't object to including it, it just seem more like something to run post-build as your suggest.

-Alan.

More information about the core-libs-dev mailing list