RFR: 8177136: Caller sensitive methods Logger.getLogger, Logger.getAnonymousLogger, and System.getLogger should throw IllegalCallerException if there is no caller on the stack.

[Daniel Fuchs]

Hi,

I now believe I was wrong in trying to tackle both
java.util.logging.Logger::getLogger and System::getLogger
uses of @CS with a single fix.
Both issues are indeed different in nature and might require
a different fix.

java.util.logging.Logger is an existing API.
the issue already exists in previous releases - and therefore
probably doesn't deserve being fixed in JDK 9 rampdown phased 2.
As David pointed out changing the specification is also probably
not the right answer here.
I have logged https://bugs.openjdk.java.net/browse/JDK-8177325
(P3) to track the possible NPE in java.util.logging.Logger


On the other hand, System::getLogger is a new API and therefore
I believe that how the method behave when there is no caller on
the stack should be specified. I will continue to use 8177136 to
track this - and I have updated the title in consequence.

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

I will send a new RFR (with the new title) and an updated
patch for this.

best regards,

-- daniel

On 20/03/2017 12:08, Daniel Fuchs wrote:
> Hi,
>
> Please find below a patch for:
>
> 8177136: Caller sensitive methods Logger.getLogger,
> Logger.getAnonymousLogger, and System.getLogger should throw
> IllegalCallerException if there is no caller on the stack.
> https://bugs.openjdk.java.net/browse/JDK-8177136
>
> Caller sensitive methods Logger.getLogger, Logger.getAnonymousLogger,
> and System.getLogger currently throw an undocumented
> NullPointerException if they are called from JNI and there is no
> Java frame on the stack.
>
> Throwing NullPointerException is confusing and makes it look like there
> is a bug in the implementation.
> In truth, these method are @CallerSensitive, and therefore must not
> be called in a context where the caller cannot be determined.
> Therefore, the right thing to do is to throw IllegalCallerException
> and document this.
>
> webrev:
> http://cr.openjdk.java.net/~dfuchs/webrev_8177136/webrev.00/
>
> As per Rampdown Phase 2 Process [1] I'd also like to get
> confirmation that this is a reasonable proposal to fix in 9.
> This fix just transmutes a NullPointerException (which should
> never happen at this point in regular usage of the API) into an
> IllegalCallerException which will help diagnosing the fact
> that the API is called from a context where it's not supposed
> to be used. The risk of fixing should therefore be very limited.
>
> best regards,
>
> -- daniel
>
> [1] Rampdown Phase 2 Process
> http://mail.openjdk.java.net/pipermail/jdk9-dev/2017-March/005666.html