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
