Bumping the version will fix the NPE? I thought you also wanted to change that super(null) to a JavaType that represents the deserializer type.

The NPE precisely occurs with com.fasterxml.jackson.core:jackson-databind:2.9.1, but does not occur with com.fasterxml.jackson.core:jackson-databind:2.9.2.
2.9.1 code:

protected StdDeserializer(JavaType valueType) {
     _valueClass = valueType.getRawClass();
}

2.9.2 code:

protected StdDeserializer(JavaType valueType) {
    // 26-Sep-2017, tatu: [databind#1764] need to add null-check back until 3.x
    _valueClass = (valueType == null) ? Object.class : valueType.getRawClass();
}

The NPE happened originally with my project because I had a transitive dependency of

auth0 -> com.fasterxml.jackson.core:jackson-databind:2.8.5
dropwizard-client -> com.fasterxml.jackson.core:jackson-databind:2.9.1
dropwizard-core ->com.fasterxml.jackson.core:jackson-databind:2.9.1

gradle's default conflict resolution strategy is

Newest: The newest version of the dependency is used. This is Gradle’s default strategy, and is often an appropriate choice as long as versions are backwards-compatible.

So because of this, my project was it forced auth0 to use com.fasterxml.jackson.core:jackson-databind:2.9.1, well this is quickly fixed by simply bumping to com.fasterxml.jackson.core:jackson-databind:2.9.2 in this project.

This will naturally have an affect on transitive dependencies in other projects based on the above default conflict resolution strategy. It will fix the the NPE issue for those projects which have a transitive dependency of com.fasterxml.jackson.core:jackson-databind:2.9.1.

It's not necessary to change other code, unless a user decides to force com.fasterxml.jackson.core:jackson-databind:2.9.1, that's not really this project's problem though in my opinion.

That makes a lot of sense. Thanks for the details 👍