I saw the thread on JDK-8177136. I share your concern that throwing ICE does not seem a good choice. I’ll reply on that thread. It seems to me that it should default to the unnamed module if no caller frame rather than throwing an exception.
For 8177036, no change in behavior. This actually fixes a regression that throws NPE that I didn’t catch during the review. Mandy > On Mar 20, 2017, at 1:29 PM, David Holmes <david.hol...@oracle.com> wrote: > > As I'm discussing in the RFR for > > "8177136: Caller sensitive methods Logger.getLogger, > Logger.getAnonymousLogger, and System.getLogger should throw > IllegalCallerException if there is no caller on the stack." > > I am quite concerned by this, seemingly sudden, problem that we have a whole > bunch of methods that now rely on there being a Java caller on the stack and > as a result if called from JNI they fail! It's fine for the internal methods > that depend on a caller to throw exceptions, but the public APIs should have > defined semantics about how they depend on any kind of "caller context" and > not just suddenly make the call illegal by throwing an IllegalCallerException > as in 8177136! > > Cheers, > David > > On 21/03/2017 4:06 AM, Mandy Chung wrote: >> >>> 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 >>
