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 at oracle.com
Tue Mar 21 12:31:59 UTC 2017
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.
I will send a new RFR (with the new title) and an updated
patch for this.
On 20/03/2017 12:08, Daniel Fuchs wrote:
> 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.
> 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.
> As per Rampdown Phase 2 Process  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
>  Rampdown Phase 2 Process
More information about the core-libs-dev