[JOHNZON-277] Fails to deserialize inner empty JSON block {} at OBJECT_START

[mkarg]

@rmannibucau Before filing another bug report I think it is better to show you this draft. It seems this time I really detected a bug. So we can discuss BEFORE posting this code to JIRA. :-)

[rmannibucau]

Agree, our offsetting does not handle that

[mkarg]

@rmannibucau Thanks for your confirmation. :-)

Filed JIRA https://issues.apache.org/jira/browse/JOHNZON-277.

[mkarg]

@rmannibucau Shall I switch PR from draft state to PR state, so you can merge the test before there is bug fix developed?

[rmannibucau]

@mkarg depends if you want to fix it or not but sure while it does not break the default build (@ignore can be fine if you dont want to do the fix yourself)

[rmannibucau]

--- a/johnzon-jsonb/src/main/java/org/apache/johnzon/jsonb/serializer/JohnzonDeserializationContext.java
+++ b/johnzon-jsonb/src/main/java/org/apache/johnzon/jsonb/serializer/JohnzonDeserializationContext.java
@@ -82,6 +82,8 @@ public class JohnzonDeserializationContext implements DeserializationContext {
                 return JsonValue.NULL;
             case VALUE_NUMBER:
                 return jsonp.createValue(parser.getBigDecimal());
+            case END_OBJECT:
+                return builderFactory.createObjectBuilder().build();
+            case END_ARRAY:
+                return builderFactory.createArrayBuilder().build();
             default:
                 throw new JsonParsingException("Unknown structure: " + next, parser.getLocation());
         }

seems enough, do you want to give it a try?

[mkarg]

@rmannibucau LOL, I actually developed exactly the same solution already :-D

Works like a charm, just pushed the commit.

[mkarg]

Ah, seems my solution is slightly different. As I know for sure that the caller was at START_OBJECT before, I simply return a constant.

[rmannibucau]

@mkarg constant is better, just misses array case I guess

[mkarg]

The array case actually cannot happen. The switch is invoked only from deserialize, which in turn is only valid to be invoked for cursor standing at KEY_NAME or START_OBJECT. So END_ARRAY can never happen. If it does happen, cursor was at invalid location when calling, hence it is more correct to throw exception than to return an empty array.

[rmannibucau]

Hmm,need to check if we cant set a deserializer in an array or collection

[mkarg]

@rmannibucau You are right. I checked the Javadocs and the same problem can occur with arrays. I will fix.

[mkarg]

@rmannibucau Fixed END_ARRAY case, too, and covered it with a unit test. Interesting side aspect: Discovered a different but related bug with empty arrays, so I actually had to ignore a piece of the test. Will look inside that other bug later and cover it with a second PR. Can you please meanwhile review and merge this one? That would be great because my team is stuck due to that original bug and waits for the Johnzon nightly build containing my fix.

[mkarg]

@rmannibucau Thanks for merging. I really appreciate your supportive and agile way to onboard new contributors! 👍 Next on my list is looking into that new bug I mentioned.

[rmannibucau]

@mkarg some people did it for me so it is the least I can do now, in particular when relevant ;). Thanks a lot for doing the PR in addition to investigate the issue, it is very appreciated.