Hi @ludekz ,

Thank you for your suggestion! The IBAN class does not implement serializable and this is intentional. I will not add the interface. However, I realise that that's not in the README, so I'll take this issue as a suggestion to add a note about that.

Here's why I don't want to implement serializable:

IBAN's have a canonical, serialized form: the string value. This is the value that's guaranteerd to be portable across system boundaries and guaranteed to remain stable through days/months/years of change. In other words, the preferred serialized form for new IBAN("NL00ABCD0123456789") is simply the string "NL00ABCD0123456789".

Reasons:

Most modern API-based systems talk JSON. In the financial sector, there's still quite a bit of XML. Some modern systems might use gRPC with protobuf, or Kafka with Avro. In all these cases, the string format is the most obvious way to pass the value.
- I have considered adding a Jackson encoder/decoder to this library, but that should really be a separate JAR file to control dependency sprawl, so the investment is a bit high. I have a unit test to make sure that the new IBAN(String) constructor can read the output of iban.toString(), and this is enough for some serialization libraries to work without further effort.
Java native serialization is so fraught with problems that Oracle is moving to get rid of Java native serialization entirely. (Apparently Mark Reinhold is on record calling it a horrible mistake).
- Specific to the scope of my IBAN library, the biggest technical problem is it wastes a lot of space, as the overhead compared to the IBAN string is hundreds of percent (I didn't create a prototype to see how much, but just the string nl.garvelink.iban.IBAN that's inevitably part of the serialized form is longer than most countries' IBANs).
- The bigger problem for me that it'd impose a big responsibility on me as a library author to make sure the Serialized form remains stable and compatible over time. The N+1 version of my library should be able to read serialized blobs written out by the N version. That commitment that has negative ROI for me, especially because the string format is a more compact serialized form anyway.
- Native serialization is so niche at this point that any serializable class which embeds an IBAN can use custom readObject/writeObject functions, readResolve/writeReplace (memento pattern) or implement java.io.Externalizable instead of java.io.Serializable. To properly deal with the backwards/forwards compatibility problems, they ought to be doing that already anyway.

I hope this is clear. If you have any follow up questions, please post below.

Cheers,
Barend

Make IBAN class Serializable #23

Description

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions