Hi Jason,

I'm not sure JDK-8145302 is the same problem: I double checked
that I could call Logger.getLogger("foo") and Logger.info("foo")
from JNI with no issue (works both with jdk8 122 and jdk9/dev).

So I'm quite puzzled about what could have caused JDK-8145302.
If Logger.getLogger() is called from a context where
there is no java frame on the stack - which I'm told might
happen with a JNI attached thread - then you will get a NPE
from Logger.getLogger. But because there's a stack trace
displayed in JDK-8145302 this does not look to be such a case.
For lack of information JDK-8145302 has been marked as incomplete.

The issue at hand (8177136) just addresses the case of
System.getLogger (which is a new API): I believe it's important
we specify what happens in the rare corner case where
this method would be called from a context where there is
no java frame on the stack.

If we get more information on JDK-8145302 then we might try
to fix that on an update (or not).

best regards,

-- daniel

On 22/03/2017 19:53, Jason Mehrens wrote:
Hi Daniel,

For my own understanding, would it be possible and yet still secure to walk up 
the call stack to substitute a caller in the case of method being defined with 
the 'native' keyword assuming it is in the same class?
For instance, if you look at the stacktrace in JDK-8145302 there is a native 
method calling 'getLogger' with a signature defined in class called MWMCR.
Then are 2 frames from the MWMCR class and 2 frames from what appears to be 
anonymous inner classes of MWMCR.

If all we care about is the calling class it seems like there are enough frames 
to choose from it just that they are not between 'getLogger' and the native 
method.

Jason

________________________________________
From: core-libs-dev <core-libs-dev-boun...@openjdk.java.net> on behalf of Daniel 
Fuchs <daniel.fu...@oracle.com>
Sent: Wednesday, March 22, 2017 1:29 PM
To: Mandy Chung
Cc: core-libs-dev
Subject: Re: [9] RFR: 8177136: Caller sensitive method System.getLogger should 
specify what happens if there is no caller on the stack.

On 22/03/2017 18:20, Mandy Chung wrote:

On Mar 22, 2017, at 10:34 AM, Daniel Fuchs <daniel.fu...@oracle.com> wrote:

http://cr.openjdk.java.net/~dfuchs/webrev_8177136/webrev.04

Looks okay.

"an {@code IllegalCallerException} is thrown.”
   - It might read better if you drop β€œan” and add a comma instead

No need to have a new webrev.

Thanks Mandy,

I updated the webrev in place. I will now proceed with all
the paperwork to get that fix in 9 ;-)

http://cr.openjdk.java.net/~dfuchs/webrev_8177136/webrev.04

-- daniel


Thanks
Mandy



Reply via email to