> On Mar 20, 2017, at 5:15 AM, Daniel Fuchs <daniel.fu...@oracle.com> wrote: > > Hi Peter, > > On 20/03/2017 12:01, Peter Levart wrote: >> Perhaps the best way to rectify those problems in one place would be for >> Reflection.getCallerClass() to return a special internal class in its >> own package, such as: >> >> jdk.internal.solitary.NoCaller >> >> ...when there is no caller. This would work correctly for class loader >> checks and would only allow invoking public exported members by core >> reflection if invoked with no caller... > > I believe this might be dangerous as it would probably hide bugs > in places where 'null' results in NPE being thrown in today's > implementation. > > Allowing the code to succeed is not always the right thing to > do, and I don't believe it can be fixed in one place. > It's probably better to let the caller of Reflection.getCallerClass() > decide what to do when null is returned, even if this means > we might have to analyze all places where @CallerSensitive is > used. >
Exactly. We ought to examine all @CS methods and determine if it handles the no caller case properly and as intended. I file a JBS issue to track this: https://bugs.openjdk.java.net/browse/JDK-8177155 FYI. Several options were discussed what StackWalker::getCallerClass should return and captured in [1]. Mandy [1] https://bugs.openjdk.java.net/browse/JDK-8140450?focusedCommentId=13867764&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13867764
