JDK-8216363 : NullPointerException in java.util.logging.Handler#isLoggable
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.util.logging
  • Affected Version: 8,11,12
  • Priority: P4
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2019-01-04
  • Updated: 2020-04-08
  • Resolved: 2019-02-21
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 11 JDK 13
11.0.6Fixed 13 b10Fixed
Sub Tasks
JDK-8219540 :  
Release Note: NullPointerException in java.util.logging.Handler#isLoggable - Closed
Description
A DESCRIPTION OF THE PROBLEM :
The JavaDoc of this method states that "It will return false if the {@code LogRecord} is null.", but there is no null-check. Instead in the second line of the method a call is done on the log record, resulting in NPE.

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Call java.util.logging.Handler#isLoggable with null argument.

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
false
ACTUAL -
NullPointerException

CUSTOMER SUBMITTED WORKAROUND :
Override the method in every handler and add a null-check

FREQUENCY : always
Comments
Approving and pushing 11u backport as failing test has been excluded from TCK.
12-11-2019
I have requested exclusion of the problematic tests. I restored the fix request label but will wait with approval until TCK issue is sorted out.
06-11-2019
This indeed breaks TCK 11. Until that is resolved, we cannot push. Removing 11u backporting labels for a while.
04-10-2019
So, will this change cause failures with the current JCK and its exclude list?
09-07-2019
Good to know, thanks.
02-07-2019
IIRC we had to challenge the JCK as some of the JCK tests wrongly expected the NPE.
02-07-2019
Fix Request (11u) This fixes the implementation to match the spec. Patch applies cleanly to 11u. New test fails without the product patch, passes with it. Also passes tier1 and tier2 tests.
02-07-2019
The possible alternative - modifying the spec to match the implementation, versus modifying the implementation to match the spec, have been discussed during the review - see here: https://mail.openjdk.java.net/pipermail/core-libs-dev/2019-February/058548.html In the end the consensus was to modify the implementation to follow the spec, and to log a bug against the two JCK tests that do not follow the spec. There will be no CSR as this was already the object of an (internal) CCC back in Java 5 - when the spec was modified to allow null. See JDK-4769466 and JCK-4920148. The JCK tests for MemoryHandler::isLoggable and MemoryHandler::publish should also have been updated at that time to match the spec, and if so they would have caught the issue, but unfortunately they remained unchanged.
21-02-2019
From submitter: There is java.util.logging.MemoryHandler which overwrites the method but just delegates to the parent for whatever reason which will also show the NPE. All other sub-classes are actually subclasses of java.util.logging.StreamHandler which overrides the method and there does the correct null-check, so it will not happen on any of the other handlers. In my own handler I followed the example and have overwritten the method with `return (record != null) && super.isLoggable(record)` to work-around this bug. If I change it to `return (record != null) && super.isLoggable(null)` or remove the override, I get the NPEs. Also if you have a look at the code of the method, it starts with public boolean isLoggable(LogRecord record) { final int levelValue = getLevel().intValue(); if (record.getLevel().intValue() < levelValue || levelValue == offValue) { return false; } where in the "if" condition "record" is dereferenced without any null-check despite the JavaDoc saying it should return "false" if the parameter is "null".
09-01-2019
Right. The spec and the implementation don't seem to be in sync. We should either change the spec to match the implementation (might be safer) or change the implementation to match the spec. I'd be in favor of replacing `It will return false if the {@code LogRecord} is null` by an implSpec note saying: @implSpec The default implementation of this method will throw a {@code NullPointerException} if the {@code LogRecord} is {@code null}. Subclasses may override this method to change this behavior (for instance, return {@code false} in that case).
08-01-2019
To submitter: Can you please provide a test case to reproduce the issue you have described in the bug report. I am not able to reproduce it by calling java.util.logging.Handler#isLoggable with null argument.
08-01-2019