Why should you not serialize to a plain text file?

Why not plain text:

• No type info: "42" could be any numeric type.
• No object graph: Cannot represent nested objects or circular references.
• Parsing fragile: Custom delimiters break on embedded delimiters.
• Better options: JSON (structured, typed), Protobuf (binary, schema-driven), Java serialization (binary, full graph).

The problem with plain text

// Writing: "SAV2001,500000,Rajesh Kumar"
// Reading: is 500000 an int, long, BigDecimal, or String?
// What if the name contains a comma: "Rajesh Kumar, Jr."?
// What about nested objects? Dates? Null values?

The JSON alternative

{"accountId": "SAV2001", "balance": 500000, "holderName": "Rajesh Kumar"}

JSON preserves structure, handles null, and is human-readable. Jackson/Gson libraries convert between Java objects and JSON automatically.

What should a senior engineer know?

• CSV is acceptable for flat tabular data but not for object graphs.
• Protobuf is more compact than JSON and has a schema for type safety.
• Avro adds schema evolution for long-term storage.
• Java serialization is a security risk – never deserialize untrusted data.

What are common mistakes?

A common mistake is forgetting to declare serialVersionUID, which causes deserialization failures when the class changes.

Wrong approach:

package com.bank.model;

import java.io.Serializable;

// WRONG: no serialVersionUID
public class Account implements Serializable {
    private String accountId;
    private java.math.BigDecimal balance;
}
// If you add a field later, old serialized data cannot be read

Correct approach:

package com.bank.model;

import java.io.Serializable;
import java.math.BigDecimal;

// CORRECT: explicit serialVersionUID
public class Account implements Serializable {
    private static final long serialVersionUID = 1L;
    private String accountId;
    private BigDecimal balance;
}
// Adding new fields with defaults still allows reading old data

Another mistake is serializing sensitive fields like passwords or PINs. Always mark them transient to exclude them from the byte stream.

What are the edge cases?

Edge cases can cause unexpected behavior in banking applications. Here are some to watch for.

package com.bank.edge;

public class EdgeCaseDemo {
    public static void main(String[] args) {
        // Edge case 1: null handling
        String accountId = null;
        try {
            System.out.println(accountId.length());
        } catch (NullPointerException e) {
            System.out.println("Null account ID");
        }

        // Edge case 2: empty vs null
        String emptyId = "";
        System.out.println(emptyId.isEmpty());  // true
        System.out.println(emptyId == null);     // false

        // Edge case 3: boundary values
        java.math.BigDecimal zero = java.math.BigDecimal.ZERO;
        java.math.BigDecimal negativeBalance = new java.math.BigDecimal("-0.01");
        System.out.println(zero.compareTo(negativeBalance) > 0);  // true
    }
}

Null account ID
true
false
true

Always test with null values, empty strings, boundary values, and negative amounts in banking applications.

What are common interview follow-up questions?

Interviewers often follow up with these related questions:

• How does this concept apply to a high-throughput banking transaction system?
• What are the performance implications in a production environment?
• How would you debug issues related to this concept?
• What tools would you use to monitor this in production?
• How does this behave differently in Java 8 vs Java 17+?

When answering follow-up questions, always relate your answer back to practical experience. For example, at National Bank of India, Rajesh debugged a production issue related to this concept by using JFR recordings and heap dumps. Providing concrete examples from banking systems shows the interviewer that you understand both the theory and the practice.