JSON আর serialization — object পাঠানো ও সংরক্ষণ

১ · object থাকে এক প্রোগ্রামের মেমরিতে — serialization কেন লাগে

পর্ব ১৫ থেকে আপনি যত object বানিয়েছেন, সবই থেকেছে একটি জায়গায়: চলমান প্রোগ্রামের heap-এ (পর্ব ৪৪-এ বিস্তারিত দেখবেন)। একটি Order object-এর ভেতরে আছে কয়েকটি field, আর তার items field আসলে একটি reference — মেমরির একটি ঠিকানা, যেখানে একটি List বসে আছে। প্রোগ্রাম বন্ধ হলে এই সব মেমরি ফেরত যায়, object-গুলো মুছে যায়। আর ঠিকানাগুলো অন্য কম্পিউটারে অর্থহীন।

অথচ বাস্তব software-এর বেশিরভাগ কাজই object-কে প্রোগ্রামের বাইরে নেওয়া। একটি খাবার-ডেলিভারি অ্যাপে গ্রাহকের ফোন অর্ডার বানায়, সেটা যায় সার্ভারের Java প্রোগ্রামে, তারপর রেস্টুরেন্টের ট্যাবলেটে। প্রোগ্রাম আলাদা, ভাষাও আলাদা হতে পারে (Kotlin, Java, JavaScript), আর কেউ কারও মেমরি দেখতে পায় না। তাই object-কে একটি সাধারণ, দুই পক্ষের বোঝার মতো ফরম্যাটে লিখে পাঠাতে হয়, আর ওপাশে সেই লেখা পড়ে আবার object বানাতে হয়।

প্রথম কাজটির নাম serialization — object-কে লেখা বা byte-এর একটি সারিতে (series) রূপান্তর। দ্বিতীয়টি deserialization — সেই লেখা থেকে আবার object বানানো। আর যে দরজা দিয়ে দুটি প্রোগ্রাম এভাবে কথা বলে, তাকে বলে API.

এই ফরম্যাট দুই ধরনের হতে পারে। লেখাভিত্তিক (text) — মানুষ পড়তে পারে, যেমন JSON, XML, CSV. আর binary — শুধু যন্ত্রের জন্য, ছোট আর দ্রুত, যেমন Protocol Buffers বা Java-র নিজস্ব serialization. এই পর্বের প্রথম ভাগ JSON, দ্বিতীয় ভাগ Java-র নিজস্ব binary serialization — পুরোনো কোডে যা আছে, আর যার বিপদ চেনা দরকার।

২ · JSON-এর ব্যাকরণ — ছয় ধরনের মান

JSON-এর পুরো ব্যাকরণ এক পাতায় ধরে যায়, আর এটাই তার শক্তি। একটি আবহাওয়া API ঢাকার আবহাওয়া জানতে চাইলে এমন একটি উত্তর দিতে পারে (কাল্পনিক উদাহরণ):

{
  "city": "Dhaka",
  "updated": "2026-10-18T09:00:00+06:00",
  "temperature_c": 31.5,
  "humidity": 78,
  "rain_expected": true,
  "alert": null,
  "forecast": [
    { "day": "2026-10-19", "max_c": 32, "min_c": 25, "summary": "হালকা বৃষ্টি" },
    { "day": "2026-10-20", "max_c": 30, "min_c": 24, "summary": "মেঘলা" }
  ]
}

এর ভেতরে মাত্র ছয় ধরনের মান আছে:

যা JSON-এ নেই, সেটাও মনে রাখুন, কারণ নতুনরা এখানেই ভুল করে: comment (//) নেই; শেষ উপাদানের পরে বাড়তি কমা (trailing comma) চলে না; একক কোট 'Dhaka' চলে না; key কোট ছাড়া লেখা যায় না; আর তারিখের আলাদা কোনো টাইপ নেই — তারিখ যায় string হিসেবে। RFC 8259 আরও বলে, সিস্টেমের বাইরে আদান-প্রদানের JSON লেখা হবে UTF-8-এ, তাই “হালকা বৃষ্টি”-র মতো বাংলা লেখা সরাসরি রাখা যায়।

৩ · Java object থেকে JSON — কোন জিনিস কোথায় যায়

এবার উল্টো দিক থেকে দেখা যাক: Java-র টাইপগুলো JSON-এ কীভাবে বসে। একটি অনলাইন দোকানের মোবাইল অ্যাপকে সার্ভার একটি অর্ডার পাঠাবে। Java-তে অর্ডারটি record দিয়ে লেখা (পর্ব ২৫):

record Item(String name, int qty, long paisa) {}
record Order(String id, String customer, List<Item> items,
             LocalDate deliveryDate, String note) {}

মেমরিতে এটা একটি object graph — একটি Order, যার field একটি List-কে দেখায়, আর List দেখায় কয়েকটি Item-কে। Serialization-এর কাজ এই গাছটিকে হেঁটে হেঁটে একটি লেখায় সাজানো। ধাপে ধাপে দেখুন:

Order ──┬─ id           = "ORD-7"
        ├─ customer     = "রনি"
        ├─ items ───────▶ List ──┬─▶ Item("চা", 2, 2000)
        │                        └─▶ Item("সিঙ্গারা", 3, 1000)
        ├─ deliveryDate = LocalDate 2026-10-20
        └─ note         = null
reference মানে মেমরির ঠিকানা — বাইরে পাঠানো যায় না

{
  "id": ...,
  "customer": ...,
  "items": ...,
  "deliveryDate": ...,
  "note": ...
}
প্রতিটি record component একটি key — নাম হুবহু component-এর নামে

{
  "id": "ORD-7",
  "customer": "রনি",
  ...
String → ডাবল কোটের ভেতরে (escape করে)
int, long → কোট ছাড়া number: 2, 2000

  "items": [
    { "name": "চা", "qty": 2, "paisa": 2000 },
    { "name": "সিঙ্গারা", "qty": 3, "paisa": 1000 }
  ],
reference-এর জায়গায় পুরো object-টাই লেখার ভেতরে বসে গেল

{
  "id": "ORD-7",
  "customer": "রনি",
  "items": [ {...}, {...} ],
  "deliveryDate": "2026-10-20",
  "note": null
}
LocalDate → ISO-8601 string; null → null (অথবা key বাদ)

টাকা আর বড় সংখ্যা নিয়ে সাবধান। JSON-এর নিয়মে সংখ্যার সীমা লেখা নেই, কিন্তু পড়ার দিকের প্রোগ্রাম সংখ্যাটা কোন টাইপে রাখবে, সেটা তার ব্যাপার। JavaScript (আর অনেক লাইব্রেরি) সব সংখ্যাকে floating-point double হিসেবে রাখে। ফলে 150.10-এর মতো মান ভেতরে নির্ভুল থাকে না, আর ২^৫৩-এর চেয়ে বড় পূর্ণসংখ্যা (যেমন কিছু বড় ID) নীরবে বদলে যায়। Java-তে টাকা রাখেন BigDecimal-এ; JSON-এ পাঠানোর সময় দুটি নিরাপদ পথ — string হিসেবে "150.50", অথবা পয়সায় গোনা পূর্ণসংখ্যা 15050. বিস্তারিত ভাবনার প্রশ্ন ৫-এ।

৪ · হাতে JSON লেখা — text block, formatted আর escaping-এর ফাঁদ

JSON তো শুধু লেখা — তাহলে লাইব্রেরি ছাড়া নিজেই String জোড়া দিয়ে বানানো যায় না? যায়, আর প্রথমবার দেখতে খুব সহজও লাগে। পর্ব ০৯-এর text block আর formatted দিয়ে:

String json = """
    {"id": "%s", "customer": "%s", "total": %d}
    """.formatted(id, customer, totalPaisa);

যতক্ষণ customer-এর নাম “রনি”, ততক্ষণ সব ঠিক। কিন্তু কেউ নামের ঘরে লিখলেন রনি "R" — একটি কোট চিহ্নসহ। তখন লেখাটা হয় "customer": "রনি "R"". JSON parser প্রথম কোট দেখে string শুরু করে, দ্বিতীয় কোটে শেষ করে, তারপর R দেখে থেমে যায় — এটা কোনো বৈধ মান নয়। আর কেউ ঠিকানা লিখতে গিয়ে Enter চাপলে নামের ভেতরে একটি নতুন লাইন চলে আসে; JSON string-এর ভেতরে কাঁচা নতুন লাইন নিষিদ্ধ। ফলে অ্যাপ অর্ডারটি পড়তেই পারে না।

সমাধান হলো escaping. RFC 8259 অনুযায়ী string-এর ভেতরে তিন রকম অক্ষর সরাসরি রাখা যায় না: ডাবল কোট (\" লিখতে হয়), backslash (\\), আর U+0000 থেকে U+001F পর্যন্ত নিয়ন্ত্রণ-অক্ষর — নতুন লাইন \n, tab \t, বা সাধারণভাবে \u000a-এর মতো। এগুলো পর্ব ০৪-এর escape sequence-এর মতোই দেখতে, কিন্তু এবার নিয়ম JSON-এর। বাংলা বা অন্য Unicode অক্ষর escape না করেই রাখা যায়। নিচের stepper-এ একটি ছোট escaper-এর ভেতর দিয়ে রনি "R" আর তারপর একটি নতুন লাইন ও “মিয়া” — এই নামটি যাচ্ছে:

1static String q(String s) {2  var sb = new StringBuilder("\"");3  for (char c : s.toCharArray()) {4    switch (c) {5      case '"'  -> sb.append("\\\"");6      case '\\' -> sb.append("\\\\");7      case '\n' -> sb.append("\\n");8      default   -> sb.append(c ...);9    }10  }11  return sb.append('"').toString();

এবার নিজে চালিয়ে দেখুন — প্রথমে ভুল পথ (সরাসরি জোড়া দেওয়া), তারপর escaper দিয়ে একটি পুরো অর্ডার:

import java.util.*;

record Item(String name, int qty, long paisa) {}

class Main {
    static String q(String s) {                       // JSON string escaper
        var sb = new StringBuilder("\"");
        for (char c : s.toCharArray()) {
            switch (c) {
                case '"'  -> sb.append("\\\"");
                case '\\' -> sb.append("\\\\");
                case '\n' -> sb.append("\\n");
                default   -> sb.append(c < 0x20 ? "\\u%04x".formatted((int) c) : String.valueOf(c));
            }
        }
        return sb.append('"').toString();
    }
    public static void main(String[] args) {
        String customer = "রনি \"R\"\nমিয়া";
        System.out.println("{\"customer\":\"" + customer + "\"}");      // ভুল পথ
        var items = List.of(new Item("চা", 2, 2000), new Item("সিঙ্গারা", 3, 1000));
        var parts = items.stream().map(i -> "{\"name\":%s,\"qty\":%d,\"paisa\":%d}".formatted(q(i.name()), i.qty(), i.paisa())).toList();
        System.out.println("{\"customer\":%s,\"items\":[%s]}".formatted(q(customer), String.join(",", parts)));
    }
}

৫ · Jackson আর Gson — লাইব্রেরি দিয়ে JSON

JDK-তে কোনো JSON লাইব্রেরি নেই, তাই Java জগতে দুটি বাইরের library সবচেয়ে প্রচলিত: Jackson (Spring Boot-এর ডিফল্ট) আর Google-এর Gson (Android-এ জনপ্রিয়)। এগুলো প্রজেক্টে যোগ হয় Maven বা Gradle দিয়ে; পর্ব ৪৬-এ বিস্তারিত দেখবেন। আপাতত শুধু চিনে রাখুন, pom.xml-এ এমন কয়েকটি লাইন লাগে:

<dependency>
    <groupId>com.fasterxml.jackson.core</groupId>
    <artifactId>jackson-databind</artifactId>
    <version>2.17.2</version>
</dependency>
<dependency>   <!-- java.time (LocalDate, Instant) সমর্থনের জন্য -->
    <groupId>com.fasterxml.jackson.datatype</groupId>
    <artifactId>jackson-datatype-jsr310</artifactId>
    <version>2.17.2</version>
</dependency>

সংস্করণ নম্বরটি উদাহরণ মাত্র; Maven Central-এ সর্বশেষ 2.x দেখে নিন। এই পর্বের Jackson কোড 2.x-এর (com.fasterxml.jackson package) জন্য লেখা — Jackson-এর নতুন বড় সংস্করণ 3.x-এ package-এর নাম আর কিছু ডিফল্ট বদলেছে। এই লাইব্রেরিগুলো অনলাইন runner-এ নেই, তাই নিচের কোডগুলো চালানো যাবে না; পাশে “প্রত্যাশিত আউটপুট” লেখা আছে।

ObjectMapper — record থেকে JSON, JSON থেকে record

Jackson-এর কেন্দ্র একটি class: ObjectMapper. একবার বানিয়ে পুরো প্রোগ্রামে ব্যবহার করা হয়। Jackson 2.12 থেকে record সরাসরি সমর্থিত — component-এর নাম দেখে key মেলায়, আর পড়ার সময় canonical constructor ডেকে object বানায়।

var mapper = new ObjectMapper();
var order = new Order("ORD-7", "রনি", List.of(new Item("চা", 2, 2000)));

String json = mapper.writeValueAsString(order);          // serialize
System.out.println(json);
// প্রত্যাশিত আউটপুট:
// {"id":"ORD-7","customer":"রনি","items":[{"name":"চা","qty":2,"paisa":2000}]}

Order back = mapper.readValue(json, Order.class);        // deserialize
System.out.println(back.equals(order));                  // প্রত্যাশিত: true

এখানে Order তিন component-এর (id, customer, items). দুটি জিনিস খেয়াল করুন। এক, কোট বা নতুন লাইনের escaping নিয়ে আপনাকে ভাবতে হয়নি। দুই, back একটি নতুন object, কিন্তু record-এর equals মান তুলনা করে, তাই true. key-এর ক্রম সাধারণত component-এর ক্রমে থাকে, তবে JSON object-এর key-এর ক্রমের কোনো অর্থ নেই — ক্রমের ওপর নির্ভর করে কোড লিখবেন না।

Generic List পড়া — TypeReference. JSON-এর শুরুতেই যদি array থাকে ([{...},{...}]), তাহলে readValue(json, List.class) লিখলে Jackson জানে না ভেতরে কী টাইপ, কারণ পর্ব ২৮-এর type erasure-এ List<Item>-এর Item চলার সময় মুছে যায়। ফল হয় Item-এর বদলে Map-এর List. সমাধান একটি type token:

List<Item> items = mapper.readValue(json, new TypeReference<List<Item>>() {});

শেষের {} লক্ষ করুন — এটা একটি ছোট anonymous class (পর্ব ২৭)। subclass-এর superclass-এর generic তথ্য class file-এ থেকে যায়, তাই Jackson reflection দিয়ে সেখান থেকে List<Item> পড়ে নেয়। Gson-এ একই কৌশলের নাম TypeToken.

যে annotation আর সেটিং প্রায় প্রতিদিন লাগে

@JsonIgnoreProperties(ignoreUnknown = true)                 // অজানা key এলে উপেক্ষা
record Txn(@JsonProperty("trx_id") String trxId,             // JSON-এ trx_id, Java-তে trxId
           TxnType type,
           BigDecimal amount,
           Instant time,
           @JsonIgnore String internalNote) {}               // JSON-এ যাবেও না, আসবেও না

var mapper = new ObjectMapper()
        .registerModule(new JavaTimeModule())                    // java.time সমর্থন
        .disable(SerializationFeature.WRITE_DATES_AS_TIMESTAMPS); // তারিখ ISO string হিসেবে

• @JsonProperty("trx_id") — JSON-এর key আর Java-র নাম আলাদা হলে।
• @JsonIgnore — ভেতরের কোনো তথ্য (পাসওয়ার্ডের hash, ভেতরের নোট) যেন কখনো JSON-এ বাইরে না যায়। এগুলো পর্ব ৪৫-এর annotation, যা Jackson চলার সময় পড়ে।
• অজানা key — Jackson 2.x-এ FAIL_ON_UNKNOWN_PROPERTIES ডিফল্টে চালু: JSON-এ record-এর বাইরের একটি key (ধরুন সার্ভার নতুন "fee" যোগ করল) এলেই UnrecognizedPropertyException. বাইরের API পড়ার সময় সাধারণত @JsonIgnoreProperties(ignoreUnknown = true) দেওয়া হয়, যাতে সার্ভার নতুন field যোগ করলে আপনার অ্যাপ ভেঙে না যায়।
• তারিখ — JavaTimeModule না দিলে Jackson 2.x LocalDate বা Instant লিখতে গিয়ে exception দেয়। module দিলেও ডিফল্টে তারিখ যায় সংখ্যা বা array হিসেবে; WRITE_DATES_AS_TIMESTAMPS বন্ধ করলে যায় "2026-10-20"-এর মতো ISO string.

Gson — Google-এর সরল বিকল্প

var gson = new Gson();
String json = gson.toJson(order);
// প্রত্যাশিত: {"id":"ORD-7","customer":"রনি","items":[{"name":"চা","qty":2,"paisa":2000}]}
Order back = gson.fromJson(json, Order.class);
List<Item> list = gson.fromJson(arrJson, new TypeToken<List<Item>>() {}.getType());

দুটি লাইব্রেরিই ভালো — একটি প্রজেক্টে একটিই বেছে নিন, যাতে নিয়ম মিশে না যায়।

Jackson একটি JSON লেখা থেকে record কীভাবে বানায়, ধাপে ধাপে দেখুন:

{"trx_id":"BK7X9Q2","type":"CASH_OUT","amount":"1000.00",
 "time":"2026-10-18T04:15:30Z","fee":"18.50"}

START_OBJECT
FIELD_NAME "trx_id"   VALUE_STRING "BK7X9Q2"
FIELD_NAME "type"     VALUE_STRING "CASH_OUT"
FIELD_NAME "amount"   VALUE_STRING "1000.00"
FIELD_NAME "time"     VALUE_STRING "2026-10-18T04:15:30Z"
FIELD_NAME "fee"      VALUE_STRING "18.50"
END_OBJECT

"trx_id" → trxId    (@JsonProperty)
"type"   → type
"amount" → amount
"time"   → time
"fee"    → ??? অজানা
ignoreUnknown = true থাকলে উপেক্ষা, না থাকলে UnrecognizedPropertyException

"CASH_OUT"             → TxnType.CASH_OUT
"1000.00"              → new BigDecimal("1000.00")
"2026-10-18T04:15:30Z" → Instant   (JavaTimeModule লাগে)
internalNote           → null      (@JsonIgnore, JSON-এ নেই)

new Txn("BK7X9Q2", CASH_OUT, 1000.00, 2026-10-18T04:15:30Z, null)
   └─▶ compact constructor-এর যাচাই চলে
Txn[trxId=BK7X9Q2, type=CASH_OUT, amount=1000.00, ...]

৬ · API-র উত্তর record-এ — লেনদেনের ইতিহাস, যাচাই আর বিশাল JSON

একটি bKash-ধাঁচের মোবাইল ওয়ালেট অ্যাপ সার্ভারের কাছে গত কয়েকটি লেনদেন চাইল। সার্ভারের উত্তর (কাল্পনিক, কিন্তু বাস্তবের মতো):

{
  "status": "OK",
  "wallet": "01700000000",
  "transactions": [
    { "trx_id": "BK7X9Q2", "type": "SEND_MONEY", "amount": "500.00",
      "time": "2026-10-18T04:15:30Z" },
    { "trx_id": "BK7X9Q3", "type": "CASH_OUT", "amount": "1000.00",
      "fee": "18.50", "time": "2026-10-18T06:02:11Z" }
  ]
}

টাকা এসেছে string হিসেবে (অংশ ৩-এর পরামর্শ মেনে), সময় ISO-8601 আকারে UTC-তে। Java-তে এর জন্য record লিখি, আর যাচাই রাখি compact constructor-এ (পর্ব ২৫):

enum TxnType { SEND_MONEY, CASH_OUT, PAYMENT }

@JsonIgnoreProperties(ignoreUnknown = true)
record Txn(@JsonProperty("trx_id") String trxId, TxnType type,
           BigDecimal amount, Instant time) {
    Txn {
        Objects.requireNonNull(trxId, "trx_id missing");
        Objects.requireNonNull(time, "time missing");
        if (amount == null || amount.signum() <= 0)
            throw new IllegalArgumentException("bad amount: " + amount);
    }
}

@JsonIgnoreProperties(ignoreUnknown = true)
record TxnHistory(String status, List<Txn> transactions) {
    TxnHistory { transactions = List.copyOf(transactions); }     // defensive copy
}

TxnHistory h = mapper.readValue(body, TxnHistory.class);
h.transactions().forEach(t -> System.out.println(t.trxId() + " " + t.amount()));
// প্রত্যাশিত আউটপুট:
// BK7X9Q2 500.00
// BK7X9Q3 1000.00

দ্বিতীয় লেনদেনে fee আছে, কিন্তু Txn-এ এমন কোনো component নেই — ignoreUnknown থাকায় সেটা নীরবে উপেক্ষিত হলো। wallet-ও একই কারণে উপেক্ষিত। ফলে সার্ভার নতুন তথ্য যোগ করলেও পুরোনো অ্যাপ চলতে থাকে।

Parse করার পর যাচাই — কেন আলাদা ধাপ

Parse সফল হওয়া মানে শুধু “লেখাটা ব্যাকরণমতো JSON আর টাইপ মিলেছে”। এর মানে এই নয় যে ডেটা সঠিক। অংশ ৫-এর stepper-এ দেখেছেন, JSON-এ একটি key না থাকলে Jackson সেই component-এ null বসায় — ভুল বা ক্ষতিকর ডেটাও নিখুঁতভাবে parse হয়। তাই যাচাইয়ের দুটি স্তর রাখুন:

• গঠনের যাচাই (compact constructor): বাধ্যতামূলক field আছে কি না, টাকা ধনাত্মক কি না, ফোন নম্বর ১১ অঙ্কের কি না। record হলে এটা যেকোনো পথে আসা object-এর জন্য চলে।
• ব্যবসার নিয়মের যাচাই (service-এর ভেতরে): এই ওয়ালেটের দৈনিক সীমা পার হলো কি না, এই trx_id আগে এসেছে কি না। এগুলোর জন্য ডেটাবেস বা অন্য তথ্য লাগে, তাই constructor-এ নয়।

বিশেষ করে বাইরে থেকে আসা JSON — মোবাইল অ্যাপের request, অন্য কোম্পানির API — সবসময় অবিশ্বস্ত ধরুন।

অ্যাপের সেটিং সংরক্ষণ

JSON শুধু নেটওয়ার্কের জন্য নয়। একটি ডেস্কটপ অ্যাপ ব্যবহারকারীর পছন্দ (থিম, লেখার আকার, ভাষা) একটি ছোট ফাইলে রাখতে পারে, যা মানুষও খুলে পড়তে ও বদলাতে পারে:

record AppSettings(String theme, int fontSize, String language) {}

Path file = Path.of("settings.json");
String text = mapper.writerWithDefaultPrettyPrinter().writeValueAsString(settings);
Files.writeString(file, text);                                   // পর্ব ৩৭
AppSettings loaded = mapper.readValue(Files.readString(file), AppSettings.class);

writerWithDefaultPrettyPrinter() JSON-কে কয়েক লাইনে সাজিয়ে লেখে, যাতে মানুষ সহজে পড়তে পারে।

বিশাল JSON — streaming

readValue পুরো JSON একবারে পড়ে সব object মেমরিতে বানায়। কিন্তু একটি ব্যাংক রাতে লাখো লেনদেনের ২ GB-র ফাইল পাঠালে সব একসাথে মেমরিতে তুলতে গিয়ে OutOfMemoryError হতে পারে। তখন লাগে streaming parser: ফাইল একটু একটু করে পড়া, একটি token বা একটি লেনদেন হাতে নিয়ে কাজ করা, তারপর সেটা ছেড়ে দেওয়া। Jackson-এ এটা সেই নিচের স্তর JsonParser (nextToken() ডেকে ডেকে এগোনো), অথবা mapper.readerFor(Txn.class).readValues(...) দিয়ে একটি একটি record পাওয়া; Gson-এ JsonReader.

৭ · Java-র নিজস্ব serialization — Serializable, transient আর serialVersionUID

JSON আসার অনেক আগে, ১৯৯৭ সালের JDK 1.1-এ Java নিজের একটি serialization ব্যবস্থা এনেছিল। উদ্দেশ্য ছিল যেকোনো object graph-কে কোনো বাড়তি কোড ছাড়াই byte-এ রূপ দেওয়া — দূরের কম্পিউটারের method ডাকা (RMI) বা object ফাইলে রাখার জন্য। ব্যবহার খুব সহজ: class-এ implements Serializable লিখলেই হলো। Serializable একটি marker interface — এর কোনো method নেই, এটা শুধু অনুমতির চিহ্ন।

লেখার কাজ করে ObjectOutputStream-এর writeObject, পড়ার কাজ ObjectInputStream-এর readObject. এই format মানুষের পড়ার মতো নয়; এর প্রথম চারটি byte সবসময় AC ED 00 05 (OpenJDK 21-এ যাচাই করা) — এবার একটি অ্যাপের সেটিং object লেখা আর পড়া দেখুন, যার একটি field transient:

Settings ─┬─ theme    = "dark"
          ├─ fontSize = 16
          └─ password = "pin1234"   transient
constructor ran   ← constructor চলল, একবার

AC ED 00 05                    stream-এর মাথা
class descriptor:
   নাম = "Settings"
   serialVersionUID = 1
   field: fontSize (int), theme (String)   ← password নেই
মান: 16, "dark"

byte[] bytes = buf.toByteArray();
এখন এটা শুধু byte — চাইলে ফাইলে রাখা যায়,
সকেটে পাঠানো যায়; এখানে মেমরিতেই রাখা হলো

stream বলে: class "Settings", UID 1
JVM: নিজের Settings class খুঁজল → UID 1 ✔ মিলেছে
Settings-এর constructor ডাকা হলো না
খালি object-এ সরাসরি বসল: fontSize = 16, theme = "dark"

Settings ─┬─ theme    = "dark"
          ├─ fontSize = 16
          └─ password = null   ← ডিফল্ট মান
dark 16 null

stream বলে: class "Settings"
filter: java.base-এর class? না → "!*" → REJECTED
object তৈরির আগেই থামল
blocked: filter status: REJECTED

এবার চালিয়ে মিলিয়ে নিন। সব কাজ মেমরিতে হচ্ছে, কোনো ফাইল লাগে না:

import java.io.*;

class Settings implements Serializable {
    private static final long serialVersionUID = 1L;
    String theme; int fontSize;
    transient String password;                       // ফাইলে যাবে না
    Settings(String t, int f, String p) { theme = t; fontSize = f; password = p; System.out.println("constructor ran"); }
}

class Main {
    public static void main(String[] args) throws Exception {
        var buf = new ByteArrayOutputStream();
        try (var out = new ObjectOutputStream(buf)) { out.writeObject(new Settings("dark", 16, "pin1234")); }
        byte[] bytes = buf.toByteArray();
        try (var in = new ObjectInputStream(new ByteArrayInputStream(bytes))) {
            var s = (Settings) in.readObject();
            System.out.println(s.theme + " " + s.fontSize + " " + s.password);
        }
        try (var in = new ObjectInputStream(new ByteArrayInputStream(bytes))) {
            in.setObjectInputFilter(ObjectInputFilter.Config.createFilter("java.base/*;!*"));
            in.readObject();
        } catch (InvalidClassException e) { System.out.println("blocked: " + e.getMessage()); }
    }
}

serialVersionUID — class-এর সংস্করণ নম্বর

stepper-এর ধাপ ৪-এ JVM serialVersionUID মিলিয়েছিল। এটা class-এর একটি সংস্করণ নম্বর, যা stream-এ লেখা থাকে। ধরুন অ্যাপের পুরোনো সংস্করণ সেটিং ফাইলে লিখেছিল UID 1 দিয়ে, আর নতুন সংস্করণে কেউ class বদলে UID 2 করলেন। পুরোনো ফাইল পড়তে গেলে (OpenJDK 21-এ যাচাই করা):

java.io.InvalidClassException: Settings; local class incompatible: stream classdesc serialVersionUID = 1, local class serialVersionUID = 2

অর্থাৎ InvalidClassException: “stream-এর class আর আমার কাছের class এক নয়”। আরও খারাপ হয় যদি আপনি serialVersionUID নিজে না লেখেন। তখন JVM class-এর গঠন (নাম, field, method, interface) থেকে একটি নম্বর হিসাব করে নেয়, আর class-এ একটি method যোগ করলেও সেই নম্বর বদলে যেতে পারে — হঠাৎ সব পুরোনো ফাইল অপাঠ্য। তাই Serializable class-এ সবসময় private static final long serialVersionUID = 1L; লিখুন। javac সাধারণভাবে এ নিয়ে কিছু বলে না; -Xlint:serial দিয়ে compile করলে সতর্ক করে:

Main.java:3: warning: [serial] serializable class Settings has no definition of serialVersionUID

আর Serializable class-এর ভেতরে এমন কোনো field থাকে, যার টাইপ নিজে Serializable নয় (এবং field-টি transient নয়), তাহলে compile ঠিকই হয়, কিন্তু লেখার সময় exception আসে — ধরুন field-এর টাইপ Order:

java.io.NotSerializableException: Order

record-এর ক্ষেত্রে নিয়ম আলাদা। পর্ব ২৫-এর ভাবনার প্রশ্ন ৪-এ দেখেছেন: Serializable record পড়ার সময় JVM canonical constructor ডাকে, তাই compact constructor-এর যাচাই চলে। তবু সবচেয়ে ভালো পছন্দ হলো Java serialization এড়িয়ে চলা — কারণ পরের অংশে।

৮ · বিপদ: অবিশ্বস্ত ডেটা deserialize করা — আর নতুন কোডে কী ব্যবহার করবেন

অংশ ২-এ বলা হয়েছিল, JSON পড়ার সময় কোন টাইপ বানানো হবে, তা ঠিক করে আপনার প্রোগ্রাম। Java serialization-এ ঠিক উল্টো: কোন class-এর object বানানো হবে, তা লেখা থাকে stream-এর ভেতরে। cast চলে object তৈরি হওয়ার পরে — ততক্ষণে যা হওয়ার হয়ে গেছে।

কী হতে পারে? অনেক class-এর ভেতরে বিশেষ method থাকে (যেমন নিজস্ব readObject), যা deserialization-এর সময় নিজে থেকে চলে। classpath-এ থাকা নিরীহ লাইব্রেরিগুলোর এমন কয়েকটি class একটির ভেতরে আরেকটি সাজিয়ে পাঠালে, একটির কাজ আরেকটিকে ডাকে, সেটি আরেকটিকে — শেষে গিয়ে কোনো একটি ক্ষতিকর কাজ ঘটে যায়, এমনকি আক্রমণকারীর পছন্দের command চালানো পর্যন্ত। এই সাজানো শিকলকে বলে gadget chain. এর জন্য আপনার কোডে কোনো bug লাগে না — classpath-এ উপযুক্ত লাইব্রেরি থাকলেই যথেষ্ট।

Java-র নকশাকারীরা নিজেরাই এ নিয়ে স্পষ্ট। Java Platform-এর প্রধান স্থপতি Mark Reinhold ২০১৮ সালে একটি সাক্ষাৎকারে ১৯৯৭ সালের এই নকশাকে একটি “ভয়ংকর ভুল” (horrible mistake) বলেছিলেন, আর তাঁর হিসাবে Java-র নিরাপত্তা-ত্রুটির অন্তত এক-তৃতীয়াংশ, হয়তো অর্ধেক, serialization-এর সাথে জড়িত। Brian Goetz ২০১৯ সালের “Towards Better Serialization” লেখায় সমস্যার মূল ধরিয়ে দেন: serialization কার্যত একটি অদৃশ্য কিন্তু public constructor, যা আপনার লেখা constructor-এর সব যাচাই পাশ কাটিয়ে যায় (অংশ ৭-এর runnable কোডে ঠিক এটাই দেখেছেন)। আর Joshua Bloch-এর Effective Java (তৃতীয় সংস্করণ) পরামর্শ দেয়: নতুন কোনো সিস্টেমে Java serialization ব্যবহারের কারণ নেই।

যদি পুরোনো কোডে থাকতেই হয় — ObjectInputFilter

পুরোনো সিস্টেম রাতারাতি বদলানো যায় না। তাই Java 9-এ JEP 290 এনেছে deserialization filter (পরে Java 8u121-সহ পুরোনো সংস্করণের আপডেটেও যোগ হয়েছে), আর Java 17-এ JEP 415 প্রতিটি প্রসঙ্গের জন্য আলাদা filter বেছে নেওয়ার ব্যবস্থা দিয়েছে। মূল নীতি allow-list: যে class-গুলো আসার কথা, শুধু সেগুলোর নাম দিন, বাকি সব !* দিয়ে নিষেধ — অংশ ৭-এর কোডের মতো। filter class-এর নাম দেখে object তৈরির আগেই থামায়। পুরো JVM-এর জন্য jdk.serialFilter system property-ও আছে। শুধু পরিচিত বিপজ্জনক class নিষেধ করা যথেষ্ট নয়, কারণ নতুন শিকল বের হতেই থাকে।

বিকল্পগুলো — কোনটি কখন

JSON-এর দুর্বলতা আকার আর গতি: প্রতিটি object-এ key-এর নাম বারবার লেখা হয়। তাই বিপুল বার্তার সিস্টেমে binary ফরম্যাট চলে — Google-এর Protocol Buffers আর Apache Avro. দুটিই ডেটার গঠন আগে থেকে একটি schema-তে লিখে রাখে, তাই key-এর নাম প্রতিবার পাঠাতে হয় না।

বেশিরভাগ REST API-র জন্য JSON-ই যথেষ্ট, আর debug করা সহজ; ভেতরের service-গুলোর মধ্যে খুব বেশি বার্তা চললে Protocol Buffers. ডেটা কীভাবে সময়ের সাথে বদলায়, তা সামলানোকে বলে schema evolution; ভাবনার প্রশ্ন ৪-এ এর গল্প। আর আধুনিক Java-তে সবচেয়ে প্রচলিত জুটি: record + JSON — record দেয় যাচাই-করা অপরিবর্তনীয় ডেটা, JSON দেয় সবার বোঝার মতো শুধু-ডেটার ফরম্যাট।

৯ · AI-এর যুগে — JSON আর serialization কোড যাচাই

AI-কে “অর্ডারটা JSON বানিয়ে পাঠাও” বললে প্রায়ই আসে String জোড়া দেওয়া কোড — দেখতে চলে, টেস্টে “রনি” দিয়ে পাস করে, আর প্রথম যে গ্রাহক নামের সাথে কোট চিহ্ন লেখেন, তাঁর অর্ডারে ভেঙে পড়ে। আবার “object ফাইলে সেভ করো” বললে অনেক সময় আসে ObjectOutputStream.

AI-এর লেখা JSON কোড হাতে পেলে — যাচাইয়ের চেকলিস্ট

• কোথাও "{\"" + ... ধরনের হাতে জোড়া JSON নেই; লেখা ও পড়া দুটোই লাইব্রেরি দিয়ে
• কোট, নতুন লাইন আর বাংলা নামসহ একটি ইনপুট দিয়ে নিজে চালিয়ে দেখেছি
• টাকা double-এ নেই; বড় ID string হিসেবে যায়
• তারিখ ISO-8601 string হিসেবে যায় ও আসে; JavaTimeModule যোগ করা আছে
• অজানা key-এর আচরণ সচেতনভাবে বাছা; JSON থেকে আসা record-এ যাচাই আছে
• readObject কোথাও বাইরের ডেটায় চলে না; পুরোনো কোডে থাকলে allow-list filter আছে
• পাসওয়ার্ড বা ভেতরের তথ্য @JsonIgnore বা আলাদা response record দিয়ে বাইরে যাওয়া থেকে আটকানো