সরাসরি প্রধান সামগ্রীতে চলে যান

জাভা ফিডব্যাক এবং স্ট্রাকচার্ড কনকারেন্সি: বিবর্তনের গল্প

Introduction

এই ভিডিওর নির্দিষ্ট অংশে জাভা ল্যাঙ্গুয়েজ আর্কিটেক্ট ব্রায়ান গোয়েটজ (Brian Goetz) আলোচনা করেছেন কীভাবে জাভার নতুন ফিচারগুলো তৈরি হয় এবং এতে সাধারণ ডেভেলপারদের মতামতের গুরুত্ব কতটুকু। বিশেষ করে Structured Concurrency-এর মতো জটিল ফিচারগুলো কেন বারবার 'Preview' অবস্থায় থাকে এবং কীভাবে কমিউনিটির ফিডব্যাক সেই ফিচারগুলোকে আরও নিখুঁত করতে সাহায্য করে, তা এখানে সহজভাবে বোঝানো হয়েছে।


১. ভালো ফিডব্যাক আসলে কী?

ভিডিও রেফারেন্স: [34:53]

ব্রায়ান গোয়েটজ বলছেন যে, জাভা টিম যখন কোনো নতুন ফিচারের খসড়া (Draft) বা প্রস্তাব (JEP) প্রকাশ করে, তখন তারা এমন কিছু জানতে চায় যা তারা নিজেরা আগে ভাবেনি।

বিস্তারিত: একজন ডেভেলপার হিসেবে আমরা যখন কোনো নতুন ফিচার দেখি, আমাদের প্রথম প্রতিক্রিয়া হয় সেটার Syntax বা লেখার ধরন নিয়ে। কিন্তু ব্রায়ানের মতে, "এই লেখাটা কেন এমন হলো?" বা "এটা কোটলিন বা স্কালা-র মতো কেন নয়?"—এই ধরনের ফিডব্যাক খুব একটা কাজে আসে না। আসল দামী ফিডব্যাক হলো সেইটা, যা নতুন কোনো বাস্তব সমস্যা (Edge Case) তুলে ধরে।

  • আমার চিন্তা: আপনি যদি কেবল দেখে মন্তব্য করেন, তবে সেটা অগভীর হয়। কিন্তু আপনি যদি সেই ফিচারটা আপনার প্রজেক্টে ব্যবহার করতে গিয়ে কোনো সমস্যায় পড়েন, তবে সেই 'অভিজ্ঞতা' জাভা টিমের জন্য সোনার মতো দামী।

২. স্ট্রাকচার্ড কনকারেন্সি (Structured Concurrency) ও এর বিবর্তন

ভিডিও রেফারেন্স: [35:58]

স্ট্রাকচার্ড কনকারেন্সি কেন এখনো 'Preview' পর্যায়ে আছে এবং কেন এটা বারবার বদলাচ্ছে, তার একটি দারুণ ব্যাখ্যা এখানে দেওয়া হয়েছে।

বিস্তারিত: স্ট্রাকচার্ড কনকারেন্সি মূলত অনেকগুলো কাজ একসাথে (Parallelly) করার সময় সেগুলোকে গুছিয়ে রাখার একটি পদ্ধতি। ব্রায়ান জানান যে, এর আগের ভার্সনগুলোতে 'Exception handling' (এরর সামলানো) কিছুটা জটিল ছিল। কমিউনিটির ফিডব্যাক পাওয়ার পর তারা বুঝতে পারেন যে সাধারণ অবস্থায় এটা ঠিক থাকলেও জটিল পরিস্থিতিতে কোড লেখা কঠিন হয়ে পড়ছে। এই কারণেই তারা 'Joiner' মেকানিজম নিয়ে আসেন যাতে কম্পাইলার নিজেই চেক করতে পারে কোড ঠিক আছে কি না।

  • সহজ ব্যাখ্যা (Easy Detail): * Structured Concurrency: মনে করুন আপনি একটি রেস্টুরেন্টে অর্ডার দিয়েছেন। আপনার জন্য পিৎজা, পানীয় এবং সালাদ তৈরি হচ্ছে। স্ট্রাকচার্ড কনকারেন্সি নিশ্চিত করে যে, সব আইটেম টেবিলে আসার পরেই বিল হবে, অথবা কোনো একটি আইটেম না পাওয়া গেলে পুরো অর্ডারটি কীভাবে সামলানো হবে তা গুছিয়ে করা।

    • Preview Feature: জাভায় কোনো নতুন জিনিস সরাসরি পাকাপাকিভাবে দেওয়া হয় না। প্রথমে এটা 'Preview' হিসেবে থাকে যাতে মানুষ ব্যবহার করে ভুলগুলো ধরিয়ে দিতে পারে।

৩. কীভাবে সঠিক ফিডব্যাক দেবেন?

ভিডিও রেফারেন্স: [39:50]

যদি কোনো ফিচার এখনো ব্যবহার করার মতো অবস্থায় না থাকে (যেমন কেবল কাগজে প্রস্তাব আছে), তবে কীভাবে ফিডব্যাক দেবেন?

বিস্তারিত: ব্রায়ান পরামর্শ দিচ্ছেন—প্রশ্ন করুন।

  • "আমি এই সমস্যায় আছি, এই ফিচারটা কি আমার এখানে কাজে লাগবে?"

  • "যদি আমি এমনভাবে কোড লিখি, তবে কী হবে?"

এই ধরনের প্রশ্নগুলো ডিজাইন টিমকে ভাবতে বাধ্য করে যে তারা কোনো গুরুত্বপূর্ণ দিক মিস করে গেল কি না।


কোডিং উদাহরণ (Code Snippet)

স্ট্রাকচার্ড কনকারেন্সির মূল লক্ষ্য হলো কোডকে নিরাপদ করা। নিচে একটি সাধারণ ধারণা দেওয়া হলো:

Java

try (var scope = new StructuredTaskScope.ShutdownOnFailure()) {
    // দুটি আলাদা কাজ শুরু করা
    Subtask<String> user = scope.fork(() -> findUser());
    Subtask<Integer> order = scope.fork(() -> fetchOrder());

    scope.join();           // সব কাজ শেষ হওয়া পর্যন্ত অপেক্ষা
    scope.throwIfFailed();  // কোনো এরর থাকলে সেটা জানানো

    // কাজ শেষে ডেটা ব্যবহার
    System.out.println(user.get() + " ordered item id: " + order.get());
} 

ব্যাখ্যা: এখানে StructuredTaskScope ব্যবহার করে আমরা নিশ্চিত করছি যে user এবং order সংক্রান্ত কাজগুলো শেষ না হওয়া পর্যন্ত প্রোগ্রাম সামনে বাড়বে না। যদি কোনো একটি কাজ ফেল করে, তবে throwIfFailed() সেটা সুন্দরভাবে হ্যান্ডেল করবে। আগে এটা করা অনেক বেশি জটিল এবং এরর-প্রবণ ছিল।


কঠিন শব্দের সহজ ব্যাখ্যা

১. Edge Case (এজ কেস): এমন কোনো পরিস্থিতি যা সচরাচর ঘটে না কিন্তু ঘটলে প্রোগ্রাম বন্ধ হয়ে যেতে পারে। যেমন: ফর্ম ফিলাপ করার সময় কেউ যদি বয়সের জায়গায় 'abc' লিখে দেয়। ২. Syntax (সিনট্যাক্স): প্রোগ্রামিং ল্যাঙ্গুয়েজ লেখার ব্যাকরণ বা নিয়ম। ৩. Checked Exception: জাভায় এমন কিছু ভুল যা প্রোগ্রাম চালানোর আগেই কম্পাইলার আপনাকে ঠিক করতে বাধ্য করে। ৪. Joiner: এটি একটি নতুন মেকানিজম যা কনকারেন্ট কাজগুলোকে একসাথে জোড়া দিতে বা রেজাল্ট সংগ্রহ করতে সাহায্য করে।


বিশ্লেষণ ও শেষ কথা

কন্টেন্ট ক্রিয়েটর এবং ব্রায়ান গোয়েটজ এখানে বোঝাতে চেয়েছেন যে, জাভা এখন আর কেবল ওরাকলের (Oracle) সম্পদ নয়, এটি একটি বিশাল কমিউনিটির সৃষ্টি।

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

পরামর্শ: আপনি যদি একজন জাভা ডেভেলপার হন, তবে নতুন Preview ফিচারগুলো আপনার প্রোডাকশন কোডে সরাসরি ব্যবহার না করলেও, একটি ছোট ডেমো প্রজেক্টে চালিয়ে দেখুন। আপনার দেওয়া একটি ছোট প্রশ্ন বা অভিজ্ঞতার রিপোর্ট জাভার পরবর্তী ভার্সনকে আরও শক্তিশালী করতে পারে। বিকল্প হিসেবে আপনি Project Loom বা Project Amber-এর মেইলিং লিস্ট ফলো করতে পারেন যেখানে এই গভীর আলোচনাগুলো চলে।

[

Carrier Classes & Discussing Syntax - Inside Java Podcast 52

Java · 3K views

](http://www.youtube.com/watch?v=b6cXuA84c9g)

মন্তব্যসমূহ

এই ব্লগটি থেকে জনপ্রিয় পোস্টগুলি

সিজ্জিন (Sijjin) vs ইল্লিয়িন (Illiyin) পার্থক্য Difference

Sijjin (سِجِّين) এবং Illiyin (عِلِّيِّين) —এ দুটি শব্দ কুরআনে এসেছে এবং দুটোই মানুষের আমলনামা সংরক্ষণ সম্পর্কিত স্থানকে নির্দেশ করে। ১. সিজ্জিন (Sijjin) সিজ্জিন হলো পাপীদের (কাফের, মুনাফিক ও দুরাচারীদের) আমলনামা সংরক্ষণের স্থান। এটি সাত তলদেশের নীচে এক কারাগার বা অন্ধকার জগতে অবস্থিত বলে উল্লেখ রয়েছে। সূরা আল-মুতাফফিফীন (৮৩:৭-৯) তে বলা হয়েছে: "كَلَّا إِنَّ كِتَابَ الْفُجَّارِ لَفِي سِجِّينٍ ۝ وَمَا أَدْرَاكَ مَا سِجِّينٌ ۝ كِتَابٌ مَرْقُومٌ" অর্থ: "না, পাপীদের আমলনামা সিজ্জিনে সংরক্ষিত। তুমি কি জানো, সিজ্জিন কী? এটি এক লিখিত দলিল।" সিজ্জিনকে একটি কারাগার, সংকীর্ণ স্থান, বা নিচের স্তরে অবস্থিত এক অন্ধকার দুনিয়া হিসেবে ব্যাখ্যা করা হয়। ২. ইল্লিয়িন (Illiyin) ইল্লিয়িন হলো সৎকর্মশীলদের (মুমিন ও নেককারদের) আমলনামা সংরক্ষণের স্থান । এটি সপ্তম আসমানের ওপরে সংরক্ষিত এক সম্মানিত স্থান। সূরা আল-মুতাফফিফীন (৮৩:১৮-২১) তে বলা হয়েছে: "كَلَّا إِنَّ كِتَابَ الْأَبْرَارِ لَفِي عِلِّيِّينَ ۝ وَمَا أَدْرَاكَ مَا عِلِّيُّونَ ۝ كِتَابٌ مَرْقُومٌ ۝ يَش...

Microservice Error Handling

একদম ঠিক বলেছেন ভাই 💯 — তুমি এখন microservice design-এর আসল beauty ধরেছো 👏 ✅ হ্যাঁ — যদি প্রতিটা service independent হয় (loosely coupled architecture), তাহলে একটা service fail করলে আরেকটা fail করবে না (at least directly না)। তবে, এখানে একটু গভীর বিষয় আছে — “independent” মানে কি logical independence, নাকি runtime independence?” এইটা বোঝা খুব জরুরি। চলো ধাপে ধাপে পরিষ্কারভাবে দেখি 👇 ⚙️ ১️⃣ Microservice Independence মানে কী? একটা system এ একাধিক service থাকে, যেমন: 🧾 Order Service 💳 Payment Service 🚚 Delivery Service ✉️ Notification Service 🔹 Logical Independence: প্রতিটা service এর নিজের data, business logic, আর deploy pipeline আলাদা। 📌 উদাহরণ: Payment service down থাকলেও Order service order create করতে পারবে (pending state এ রাখবে)। Delivery service নিজের data manage করবে, Payment এর DB access করবে না। 👉 মানে “tight coupling” নেই — service গুলা নিজের domain handle করে। 🔹 Runtime Independence: প্রতিটা service run হয় আলাদা instance/container এ। তাদের মধ্যে ...