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
