Retro-compatibility with dates between v9 and v10

[Alban42]

Hello,

Between v9 and V10 versions, the dates format have changed.
I don’t see anything in the v10 to be compatible with v9 date format.

Is there any custom adapter (or possibility to add one) to able to deserialize the « old » date format (or any other solution ) ?

Many thanks in advance.
Regards

[elominp]

Hello,

@zubri

I'm upping the issue because this causes compatibility troubles between applications using the v9 library and the ones migrated to the v10.

Date fields are still working but the DateTime fields have changed format, causing an application using the v10 library to read null instead of the expected value when parsing JSON received or saved on storage based on the previous version of the library.

We found in your documentation that you mention this compatibility issue but with no concrete documentation on how to handle it.

What method do you recommend to handle this? Can we expect the JSON parser in v10 to be able to parse old datetime format (or a PR for this to be accepted, even if it will be "deprecated" and possibly removed in a v11) ?

Do you recommend a configuration to pass in the library to tweak the JSON parser and have custom code to handle datetimes of the previous format?

Must we convert all stored MX in JSON format back to XML with v9 based version of the application then parse & convert them again to JSON with the v10 based version?

Regards

[zubri]

Hi,

Moving from the legacy Calendar for all type of date and time fields into a more modern model based on the new java.time model classes was indeed a breaking change. That's the reason why we made it in a major yearly release from 9 to 10.

For the jaxb serialization back and forth the XML we do have some public API in the library where you can set your own adapters. However, for JSON it is fixed in the private implementation.

Anyway, if you need to work with legacy JSON in version 10, one option is to create your own JSON parser/writer. The code is basically Gson on the AbstractMX class using custom adapters. Something like this:

final Gson gson = new GsonBuilder()
.registerTypeAdapter(AbstractMX.class, new AbstractMXAdapter())
.registerTypeAdapter(OffsetDateTime.class, new OffsetDateTimeJsonAdapter())
.registerTypeAdapter(OffsetTime.class, new OffsetTimeJsonAdapter())
.registerTypeAdapter(LocalDate.class, new LocalDateJsonAdapter())
.registerTypeAdapter(Year.class, new YearJsonAdapter())
.registerTypeAdapter(YearMonth.class, new YearMonthJsonAdapter())
.registerTypeAdapter(AppHdr.class, new AppHdrAdapter())
.create();
String json = gson.toJson(this, AbstractMX.class);

And you can actually extend the library default adapters to tweak them.

Besides this workaround, I will check and maybe we can have a 'fromJsonV9' and 'toJsonV9' directory in the model to give backward compatibility with ease.

[elominp]

Hello @zubri ,

Thanks for your answer.

For now I think the update on the SRU2024 seems to work on the messages we are using, was there other major differences than the GregorianCalendar? Also yes we had checked in the library how the JSON is parsed and as you said it's fixed in the private implementation, an interface / method to tweak the adapters would sure be useful in a generic way without forking the code and a fromJsonV9 method would really simplify migrations 🙂

[zubri]

We have added added backward compatibility methods fromJsonV9 and toJsonV9 to consume or produce the legacy JSON structures that we use to have for Gregorian Calendar. The adapter converts that into the java.time structure of the v10 model.

https://dev.prowidesoftware.com/SRU2024-10/open-source/iso20022/iso20022-mx-json/#backward-compatibility-version-9

This is available in SRU2024-10.2.4 and SRU2023-10.1.8