Make IBAN class Serializable

[ludekz]

Hello,
I suggest to make IBAN class implement interface Serializable.

[barend]

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

[barend]

Can you tell me what particular technology/library/platform you use that requires native serialization?

[ludekz]

Thank you for reply.
We use Hazelcast as distributed cache among server nodes.

I will think about possible solutions. Maybe we dont need to stora data in IBAN class, we can use it just for basic input validation and store just plain String.

[barend]

Hmm, I hadn't considered distributed cache as a use case. I'll prototype a bit what serialization would look like, and whether it comes out in a way that I'm willing to support. I'll keep you posted.

[barend]

@ludekz I found a format that I'm willing to support, see commit 5bf7633 for details.

[ludekz]

It looks good. Nice job.

[barend]

@ludekz I just published the new release to Maven Central; it still needs some time to get through the CDN. New version number is 1.8.0.