You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
All the Ion core types have different null values (null.struct, null.list etc) and the fix that comes with #295 provides proper deserialization of these different null types. But it doesn't handle java nulls correctly.
Apart from these different null values, Ion also has a raw null type which implements IonNull interface. Only this raw null type implements IonNull and the other null values (null.struct, null.list etc) are valid IonValues and they are NOT implementing IonNull interface.
publicinterfaceIonNullextendsIonValue
When serialized, Java nulls are translated into Ion’s raw null type and they become IonNull. And naturally when deserialized it returns this IonValue (aka IonNull) which doesn’t match with Java null and causes the test listed above to fail.
Solution Proposal
We can fix this issue by adding an extra check when deserializing null values. If the embedded object is actually an IonNull then it returns java null as deserialization response. Of course this will NOT affect the other type specific null values like null.struct or null.list etc. because they are not an instance of IonNull so they will continue to be deserialized into their respective type.
Here is the proposal for getNullValue method with this extra IonNull check. (The code below also includes the fix proposal for #317)
The only problem left is when we specifically try to serialize IonNull type. Then there will be no way to discriminate these from java nulls because both of them will be converted into same Ion definition which causes deserialization to fail.
As per my understanding the test case below can never pass.
The reason that this test case is impossible can easily be understood by looking at the output of the debug line:
[junit] Serialized IonValue:{a:null,b:null}
Both Java null and Ion null is converted into IonNull so whatever we decide to return from deserialization either IonNull (current status) or java null (proposal) both of them will always receive the same value so we can not satisfy this test case.
As far as I know, we don’t usually serialize raw IonNulls but we definitely want to serialize Java nulls.
Also as it is mentioned in Ion Specification the raw null type in Ion exists primarily for compatibility reasons. Since they are used to represent java nulls in ion world and when deserialized they need to be converted back to java nulls.
If we move forward with the proposal we need to remove this test case from IonValueDeserializerTest suite since it will fail.
Problem definition
This simple test case that I have added to IonValueDeserializerTest class fails:
All the Ion core types have different null values (null.struct, null.list etc) and the fix that comes with #295 provides proper deserialization of these different null types. But it doesn't handle java nulls correctly.
Apart from these different null values, Ion also has a raw null type which implements IonNull interface. Only this raw null type implements IonNull and the other null values (null.struct, null.list etc) are valid IonValues and they are NOT implementing IonNull interface.
When serialized, Java nulls are translated into Ion’s raw null type and they become IonNull. And naturally when deserialized it returns this IonValue (aka IonNull) which doesn’t match with Java null and causes the test listed above to fail.
Solution Proposal
We can fix this issue by adding an extra check when deserializing null values. If the embedded object is actually an IonNull then it returns java null as deserialization response. Of course this will NOT affect the other type specific null values like null.struct or null.list etc. because they are not an instance of IonNull so they will continue to be deserialized into their respective type.
Here is the proposal for getNullValue method with this extra IonNull check. (The code below also includes the fix proposal for #317)
Remaining issue
The only problem left is when we specifically try to serialize IonNull type. Then there will be no way to discriminate these from java nulls because both of them will be converted into same Ion definition which causes deserialization to fail.
As per my understanding the test case below can never pass.
The reason that this test case is impossible can easily be understood by looking at the output of the debug line:
Both Java null and Ion null is converted into IonNull so whatever we decide to return from deserialization either IonNull (current status) or java null (proposal) both of them will always receive the same value so we can not satisfy this test case.
As far as I know, we don’t usually serialize raw IonNulls but we definitely want to serialize Java nulls.
Also as it is mentioned in Ion Specification the raw null type in Ion exists primarily for compatibility reasons. Since they are used to represent java nulls in ion world and when deserialized they need to be converted back to java nulls.
If we move forward with the proposal we need to remove this test case from IonValueDeserializerTest suite since it will fail.
The text was updated successfully, but these errors were encountered: