[9] RFR: 8177136: Caller sensitive method System.getLogger should specify what happens if there is no caller on the stack.

[Brent Christian]

Hi, Daniel

I think the new @throws tag gives a good explanation of the situation, 
with instructions for someone wanting to get a System.Logger from JNI.

To nitpick on style, it's maybe on the long side for an @throws - 
perhaps consider a slightly more concise version:

      * @throws IllegalCallerException if there is no {@linkplain
      *         StackWalker#getCallerClass() caller} frame, i.e.
      *         this method is called from JNI
      *         and there is no Java frame on the stack.<br>
      *         To obtain a logger in such a context, the caller
      *         should either use an auxiliary class that will implicitly
      *         be identified as the caller, or use the system {@link
      *         LoggerFinder#getLoggerFinder() LoggerFinder} to
      *         obtain a logger. Note that doing the latter
      *         may eagerly initialize the underlying logging
      *         system.

Thanks,
-Brent

On 3/21/17 5:44 AM, Daniel Fuchs wrote:
> Hi,
>
> Please find below an updated patch for:
>
> 8177136: Caller sensitive method System.getLogger should  specify
>          what happens if there is no caller on the stack.
> https://bugs.openjdk.java.net/browse/JDK-8177136
>
> webrev:
> http://cr.openjdk.java.net/~dfuchs/webrev_8177136/webrev.01
>
> System.getLogger(name) and System.getLogger(name, resourceBundle)
> are specified to call LoggerFinder to obtain a logger, which requires
> the module of the caller class.
> When there is no java frame on the stack, then the caller information
> cannot be obtained and there is not enough context to know which module
> would be appropriate.
> The proposal is to throw IllegalCallerException - which is the exception
> that StackWalker::getCallerClass will throw if called by
> System::getLogger in this case.
>
> This RFR follows the discussion started here:
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-March/046868.html
>
> best regards,
>
> -- daniel