-
-
Notifications
You must be signed in to change notification settings - Fork 1.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Null-safe equality check #1292
Null-safe equality check #1292
Conversation
Before adding such a check, it would be good to be able reproduce the problem: I don't want to be hiding issues where |
Agreeing to your point there. However, I've started getting these errors when I use version 2.8.0 of jackson-databind.
|
@hipatel7 Ok. This is bit worrisome also from perspective that perhaps it could also cause incorrect behavior when exception would otherwise be thrown... do you think this would be due to concurrency (something accessing half-resolved type), or not? If it is, reproduction could be challenging. Another question on version: which version are upgrading from? 2.7 or earlier? If 2.7, I wonder if this could be due to caching that was to be added; and if so, whether I have to re-consider caching of generic types. |
I tested it, up to 2.7.5 it works. In 2.8.0, I see these errors. This isn't related to concurrency. I can see this error even from a single threaded unit test. |
@hipatel7 Ok. The reason I asked about concurrency was since I was guessing this might be related to caching. It may still be -- there is one specific change to caching that is included in 2.8.0, but not in 2.7.x -- but fortunately it should be easier to reproduce. |
Fixed #1297, which while not necessarily related would be in sort of some area. It would be great to get a reproduction to fix the problem for 2.8.1. |
@cowtowncoder I am also facing this issue. I can not upgrade it to version 2.8.1. Can you suggest alternate way of parsing MAP to JSON. |
@jajoriaprerna 2.8.1 has not yet been released, but will be soon. The only work-around I can think of is to change type signature of the class that triggers the problem, but that may not be practical. |
Fixed via #1302 |
This equality check needs to be null-safe. It appears that getSelfReferencedType() may not be always non-null. Due to this, I have seen null pointer exceptions thrown from ResolvedRecursiveType.equals() .
Here's one example where object of type ResolvedRecursiveType is created which could return null for getSelfReferencedType() calls. :