annotation আর reflection — Spring আর JUnit-এর “জাদু”র ভেতরে

১ · লেবেল আর আয়না — annotation আর reflection কেন একসাথে

পর্ব ২০-এ method override করার সময় ওপরে লিখেছিলেন @Override. পর্ব ২৮-এ দেখেছেন @SuppressWarnings("unchecked"). আর মডিউল ৭-এ Spring Boot আর JUnit-এ এমন @-চিহ্ন আরও অনেক দেখবেন: @Test, @Component, @GetMapping("/users"). এগুলোর নাম annotation. প্রথম যে কথাটা বুঝতে হবে, সেটা একটু অবাক করার মতো: annotation নিজে কিছুই করে না।

কারা পড়ে? তিন ধরনের পাঠক আছে, আর তারা তিনটি আলাদা সময়ে কাজ করে:

তৃতীয় পাঠকের জন্য দরকার একটি বিশেষ ক্ষমতা — প্রোগ্রাম চলার সময় নিজের class-গুলোর ভেতরটা দেখা। এর নাম reflection, মানে প্রতিফলন: প্রোগ্রাম আয়নায় নিজেকে দেখছে। সাধারণ কোডে আপনি জানেন কোন class, কোন method — account.deposit(500) লেখেন, compiler যাচাই করে। reflection-এ নাম আগে জানা থাকে না; চলার সময় প্রশ্ন করা হয়: “এই class-এ কোন কোন method আছে? কোনটার গায়ে @Test লেবেল? সেটা ডাকো।”

২ · Java-র নিজের annotation — compiler যা পাহারা দেয়

JDK-র সাথে কয়েকটি annotation আসে, যেগুলো মূলত compiler পড়ে। এগুলো দিয়ে শুরু করা ভালো, কারণ এদের কাজ চোখে দেখা যায় — ভুল করলে compile error বা warning আসে। নিচের ছোট ফাইলে তিনটি ভুল ইচ্ছা করে রাখা হয়েছে:

import java.lang.annotation.*;

@Target(ElementType.METHOD)
@interface MyTest {}

@FunctionalInterface
interface FeeRule {
    double fee(long amount);
    String name();
}

@MyTest
class Account {
    @Override
    public String tostring() { return "Account"; }
}

class Main {
    public static void main(String[] args) { }
}

Main.java:12: error: annotation interface not applicable to this kind of declaration
@MyTest
^
Main.java:6: error: Unexpected @FunctionalInterface annotation
@FunctionalInterface
^
  FeeRule is not a functional interface
    multiple non-overriding abstract methods found in interface FeeRule
Main.java:14: error: method does not override or implement a method from a supertype
    @Override
    ^
3 errors

OpenJDK 21-এ যাচাই করা এই তিনটি বার্তা তিনটি আলাদা পাহারার গল্প বলে। নিচ থেকে শুরু করা যাক।

@Override — বানান ভুলের পাহারাদার। লেখার কথা ছিল toString, লেখা হয়েছে tostring (ছোট হাতের s). @Override না থাকলে এটা একটি নতুন, আলাদা method হতো — কোনো error নেই, কিন্তু println(account) আগের মতো অর্থহীন লেখা ছাপত। লেবেল থাকায় javac বলল: “এটা কিছুই override করছে না”। পর্ব ২০-এ এই কারণেই বলা হয়েছিল, override করলে সবসময় @Override দিন।

@FunctionalInterface — নকশার প্রতিশ্রুতি। পর্ব ৩৪-এ দেখেছেন, lambda বসানো যায় শুধু এমন interface-এ, যার abstract method ঠিক একটি (functional interface). FeeRule-এ দুটি, তাই javac আপত্তি করল। লেবেলটা না দিলেও interface একটি method থাকলে functional হয়; লেবেল দেওয়ার লাভ হলো ভবিষ্যতে কেউ ভুল করে দ্বিতীয় abstract method যোগ করলে সাথে সাথে ধরা পড়বে — যারা এই interface-এ lambda বসিয়েছে, তাদের কোড ভাঙার আগেই।

@Target — লেবেল কোথায় লাগানো যাবে। MyTest বানানো হয়েছে শুধু method-এর জন্য, অথচ লাগানো হয়েছে class-এ। এটা আমাদের নিজের annotation — অংশ ৩-এ বিস্তারিত দেখবেন।

@Deprecated — “এটা আর ব্যবহার করবেন না”

লাইব্রেরি বড় হলে কিছু পুরোনো method-এর জায়গায় ভালো method আসে। পুরোনোটা সাথে সাথে মুছে দিলে হাজারো ব্যবহারকারীর কোড ভেঙে যাবে। তাই আগে ঘোষণা: deprecated — “আছে, কিন্তু এড়িয়ে চলুন”। Java 9 থেকে @Deprecated-এ দুটি element আছে: since (কোন সংস্করণ থেকে) আর forRemoval (ভবিষ্যতে সত্যিই মুছে ফেলা হবে কি না)।

class Legacy {
    @Deprecated(since = "2.0")
    static int oldFee(int amount) { return amount / 50; }

    @Deprecated(since = "2.0", forRemoval = true)
    static int veryOldFee(int amount) { return amount / 40; }
}

class Main {
    public static void main(String[] args) {
        System.out.println(Legacy.oldFee(1000));
        System.out.println(Legacy.veryOldFee(1000));
    }
}

সাধারণভাবে javac Main.java চালালে প্রোগ্রাম compile হয় (আর চালালে 20 ও 25 ছাপে), কিন্তু javac এটুকু বলে:

Main.java:12: warning: [removal] veryOldFee(int) in Legacy has been deprecated and marked for removal
        System.out.println(Legacy.veryOldFee(1000));
                                 ^
Note: Main.java uses or overrides a deprecated API.
Note: Recompile with -Xlint:deprecation for details.
1 warning

লক্ষ করুন পার্থক্যটা: forRemoval = true হলে পুরো warning আসে, সাধারণ deprecation-এ শুধু একটি ছোট Note. বিস্তারিত দেখতে javac -Xlint:deprecation Main.java দিলে দুটি লাইনের জন্যই warning আসে — warning: [deprecation] oldFee(int) in Legacy has been deprecated আর ওপরের [removal] লাইনটি। (একটি সূক্ষ্ম নিয়ম: একই class-এর ভেতর থেকে নিজের deprecated method ডাকলে warning আসে না, তাই উদাহরণে Legacy আর Main আলাদা।) ভালো অভ্যাস হলো @Deprecated-এর সাথে Javadoc-এ @deprecated ট্যাগে বিকল্পের নাম লিখে দেওয়া: “এর বদলে cashOutFee() ব্যবহার করুন”।

@SuppressWarnings আর @SafeVarargs পর্ব ২৮-এ generics-এর সাথে দেখেছেন। দুটোই compiler-কে বলে “আমি জানি, আমি দায়িত্ব নিচ্ছি”। তাই এগুলো যত ছোট পরিসরে সম্ভব — পুরো class-এ নয়, একটি method বা একটি variable-এ — বসানো উচিত।

৩ · নিজের annotation বানানো — @interface, retention আর target

নিজের লেবেল বানাতে @interface লিখতে হয় (interface-এর আগে @)। ভেতরে যা লেখেন, সেগুলো দেখতে method-এর মতো, কিন্তু আসলে লেবেলের ঘর — এদের বলে element:

import java.lang.annotation.*;

@Retention(RetentionPolicy.RUNTIME)          // চলার সময় পর্যন্ত টিকে থাকবে
@Target(ElementType.METHOD)                  // শুধু method-এ লাগানো যাবে
@Documented                                  // Javadoc-এ দেখাবে
@interface Command {
    String name();                           // বাধ্যতামূলক element
    String help() default "";                // default থাকলে ঐচ্ছিক
    int minArgs() default 0;
}

// ব্যবহার:
@Command(name = "add", help = "নতুন খরচ যোগ করুন", minArgs = 2)
void addExpense(String[] args) { ... }

element-এর টাইপ হতে পারে শুধু primitive, String, Class, enum, অন্য annotation, অথবা এদের array — কারণ মানগুলো compile-এর সময় জানা থাকতে হয় আর .class ফাইলে লিখে রাখতে হয়। element-এর নাম value হলে ব্যবহারের সময় নাম না লিখলেও চলে: @Min(18) মানে @Min(value = 18). কোনো element-ই না থাকলে (যেমন @MyTest) সেটা শুধু একটি চিহ্ন — পর্ব ২১-এর marker interface-এর আধুনিক বিকল্প।

ওপরের @Retention, @Target, @Documented নিজেরাও annotation — তবে এরা অন্য annotation-এর গায়ে বসে। এদের বলে meta-annotation. সবচেয়ে গুরুত্বপূর্ণ retention policy: লেবেলটা কতদূর পর্যন্ত টিকে থাকবে। এই সিদ্ধান্তই ঠিক করে কোন পাঠক লেবেলটা দেখতে পাবে। ধাপে ধাপে দেখুন:

@Override                      // Retention: SOURCE
@NoRetention                   // @Retention লেখা নেই → ডিফল্ট CLASS
@Live                          // @Retention(RUNTIME)
public String toString() { ... }

@Override  → যাচাই: সত্যিই override? ✔
           → কাজ শেষ, লেবেল ফেলে দেওয়া হলো
@NoRetention, @Live → .class-এ লেখার জন্য রাখা হলো
annotation processor-ও (Lombok ইত্যাদি) এই ধাপেই চলে —
তারা SOURCE লেবেলও দেখতে পায়

RuntimeInvisibleAnnotations:  @NoRetention   ← CLASS
RuntimeVisibleAnnotations:    @Live          ← RUNTIME
@Override এখানে নেই — javap দিয়ে খুঁজলেও পাবেন না
CLASS লেবেল bytecode টুলের জন্য (যেমন কোড বিশ্লেষক)

m.isAnnotationPresent(NoRetention.class)  → false
m.isAnnotationPresent(Live.class)         → true
JVM class লোড করার সময় invisible অংশ পড়েই না
(OpenJDK 21-এ চালিয়ে যাচাই করা ফল)

@Target আর বাকি meta-annotation

@Target বলে লেবেল কোথায় লাগানো যাবে: TYPE (class, interface, enum, record), METHOD, FIELD, PARAMETER, CONSTRUCTOR, RECORD_COMPONENT (Java 16 থেকে) ইত্যাদি; একাধিক দিতে চাইলে @Target({ElementType.FIELD, ElementType.METHOD}). ভুল জায়গায় লাগালে অংশ ২-এর সেই বার্তা: annotation interface not applicable to this kind of declaration. বাকি তিনটি:

• @Inherited: class-এ লাগানো লেবেল subclass-ও “উত্তরাধিকারসূত্রে” পায়। @Audited class Base আর class Child extends Base হলে Child.class.isAnnotationPresent(Audited.class) দেয় true. শুধু class-এর জন্য কাজ করে, method বা interface-এর জন্য নয়।
• @Repeatable (Java 8 থেকে): একই লেবেল একই জায়গায় একাধিকবার: @Role("admin") @Role("teller"). এর জন্য একটি “ধারক” annotation লাগে (@interface Roles { Role[] value(); }), আর compiler আসলে দুটি লেবেলকে একটি @Roles-এ মুড়ে রাখে। তাই পড়ার সময় getAnnotationsByType(Role.class) ব্যবহার করুন — এটা দেয় [admin, teller]; অথচ isAnnotationPresent(Role.class) দেয় false, কারণ সরাসরি আছে শুধু @Roles (OpenJDK 21-এ যাচাই করা)।
• @Documented: Javadoc তৈরির সময় annotation-টি ডকুমেন্টেশনে দেখায়। public API-র লেবেলে দেওয়া ভালো।

৪ · reflection-এর শুরু — Class object আর class-এর ভেতর দেখা

reflection-এর দরজা হলো Class object. পর্ব ০৫-এ দেখেছেন, class loader একটি .class ফাইল মেমরিতে আনে। আনার সময় JVM সেই class-এর বর্ণনা হিসেবে একটি java.lang.Class object বানায় — class-এর নাম, field, method, constructor, annotation সবকিছুর তালিকা। এই object পাওয়ার তিনটি উপায়:

Account a = new Account();
Class<?> c1 = a.getClass();                 // হাতে object আছে
Class<?> c2 = Account.class;               // compile-এর সময় টাইপ জানা
Class<?> c3 = Class.forName("Account");    // শুধু নাম জানা — String থেকে (পুরো package-সহ নাম)

System.out.println(c1 == c2 && c2 == c3);                    // true
System.out.println(Class.forName("java.util.ArrayList").getName()); // java.util.ArrayList
System.out.println(int[].class.getName());                     // [I

তিনটিই একই object দেয় — প্রতিটি class loader-এ প্রতিটি class-এর Class object একটিই। তৃতীয় উপায়টি সবচেয়ে শক্তিশালী: class-এর নাম একটি String, যা কনফিগারেশন ফাইল, ডেটাবেস বা ব্যবহারকারীর কাছ থেকে আসতে পারে। পুরোনো JDBC কোডে Class.forName("com.mysql.cj.jdbc.Driver") দেখবেন পর্ব ৪৯-এ — ঠিক এই কৌশল। নাম ভুল হলে ClassNotFoundException (একটি checked exception) আসে, যার বার্তা শুধু নামটি: Acount. (array-এর নাম [I দেখে ঘাবড়াবেন না — এটা JVM-এর ভেতরের লেখার রীতি, “int-এর array”.)

getDeclared* বনাম get* — দুটি আলাদা প্রশ্ন

এবার এই class-টির ভেতর দেখা যাক:

class Account {
    private long balance = 500;
    public String owner = "Rahim";
    public Account() { }
    private Account(long b) { balance = b; }
    public long getBalance() { return balance; }
    private void audit() { }
    public void deposit(long x) { balance += x; }
}

Class object-কে দুইভাবে প্রশ্ন করা যায়, আর উত্তর একেবারে আলাদা (OpenJDK 21-এ চালানো, নাম অনুযায়ী সাজানো):

getDeclaredMethods(): [audit, deposit, getBalance]
getMethods():         [deposit, equals, getBalance, getClass, hashCode, notify, notifyAll, toString, wait]
getDeclaredFields():  [balance, owner]
getFields():          [owner]
getDeclaredConstructors(): 2টি    getConstructors(): 1টি

তাই getMethods()-এ audit নেই (private), কিন্তু Object থেকে আসা equals, hashCode, wait আছে। একটি নির্দিষ্ট method চাইলে নাম আর parameter টাইপ দিয়ে খুঁজুন: Account.class.getMethod("deposit", long.class). এমন method না থাকলে আসে NoSuchMethodException, বার্তা Account.withdraw().

চলার সময় annotation পড়া

Class, Method, Field, Constructor, RecordComponent — সবাই একই প্রশ্নের উত্তর দিতে পারে:

• isAnnotationPresent(Live.class) — লেবেল আছে কি না, true/false.
• getAnnotation(Command.class) — লেবেলটি নিজে, না থাকলে null. তারপর cmd.name(), cmd.minArgs() ডেকে element-এর মান পড়া যায় — যেন annotation একটি interface আর তার মান method.
• getAnnotationsByType(Role.class) — repeatable লেবেলের সব কপি।

মনে রাখবেন, এই প্রতিটি প্রশ্ন কাজ করে শুধু RUNTIME retention-এর লেবেলের জন্য।

৫ · দেখা থেকে করা — method ডাকা, object বানানো, private ছোঁয়া

শুধু দেখলে framework হয় না; খুঁজে পাওয়া method ডাকতে হবে, class থেকে object বানাতে হবে। তিনটি মূল কাজ:

Class<?> cls = Class.forName("Account");
Object b = cls.getDeclaredConstructor().newInstance();    // new Account() — নাম না জেনেই
Method dep = cls.getMethod("deposit", long.class);
dep.invoke(b, 250L);                                      // b.deposit(250)
System.out.println(((Account) b).getBalance());          // 750

Field f = cls.getDeclaredField("balance");                // private field
f.setAccessible(true);                                    // access-এর পাহারা বন্ধ
f.setLong(b, 999);
System.out.println(((Account) b).getBalance());          // 999

getDeclaredConstructor() (parameter ছাড়া) খালি constructor খোঁজে, আর newInstance() সেটা ডাকে। পুরোনো কোডে cls.newInstance() দেখবেন — Java 9 থেকে এটা deprecated, কারণ constructor-এর ছোড়া checked exception-ও এটা কোনো মোড়ক ছাড়া পার করে দিত। Method.invoke(object, argument...) ডাকে method; static method হলে প্রথম argument null. invoke-এর argument Object..., তাই টাইপ মিলছে কি না compiler দেখে না। 250 দিলে সেটা Integer হয়ে যায়, আর reflection তাকে long-এ widening করে ঠিকই নেয়; কিন্তু উল্টো দিকে — int parameter-এ 5L, বা long-এ একটি String — চলার সময় আসে IllegalArgumentException: argument type mismatch (OpenJDK 21-এ যাচাই করা)। সরাসরি ডাকলে এই ভুল compile-এর সময়েই ধরা পড়ত।

InvocationTargetException — মোড়কের ভেতরের আসল ভুল

ধরুন ডাকা method নিজেই exception ছুড়ল — deposit(-5) হলে IllegalArgumentException. সরাসরি ডাকলে আপনি সেটাই পেতেন। কিন্তু invoke দিয়ে ডাকলে reflection সেটাকে একটি মোড়কে ভরে দেয়: InvocationTargetException. এর কারণ হলো আলাদা করা: “reflection-এর নিজের সমস্যা” (ভুল argument, access নেই — এগুলো সরাসরি IllegalArgumentException/IllegalAccessException) আর “আপনার ডাকা method-এর ভেতরের সমস্যা”। আসল exception থাকে e.getCause()-এ (পর্ব ২৯-এর exception chaining). অংশ ৬-এর test runner-এ এটা চোখে দেখবেন — সেখানে FAIL ... -> java.lang.IllegalArgumentException: amount must be positive লাইনটি আসে getCause() থেকে।

setAccessible আর module-এর দেয়াল

setAccessible(true) reflection-কে private member ছুঁতে দেয় — পর্ব ১৭-এর encapsulation-কে পাশ কাটিয়ে। Hibernate এভাবে private field-এ ডেটাবেসের মান বসায়, Jackson private field পড়ে JSON বানায়। নিজের কোডের ক্ষেত্রে (একই module, এখানে “unnamed module”) এটা চলে। কিন্তু JDK-র নিজের ভেতরে হাত দিতে গেলে:

Field v = String.class.getDeclaredField("value");   // String-এর ভেতরের byte[]
v.setAccessible(true);                              // InaccessibleObjectException

Unable to make field private final byte[] java.lang.String.value accessible: module java.base does not "opens java.lang" to unnamed module @4b55eca5

শেষের @4b55eca5 একটি পরিচয়-সংখ্যা, প্রতিবার চালালে আলাদা হতে পারে; বাকিটা হুবহু (OpenJDK 21-এ যাচাই করা)। InaccessibleObjectException একটি unchecked exception. পর্ব ১৭-এ module-এর কথা বলা হয়েছিল: Java 9 থেকে JDK নিজে module-এ ভাগ করা, আর java.base module তার ভেতরের package-গুলো reflection-এর জন্য “open” করে না। Java 9 থেকে 15 পর্যন্ত এই নিষেধ শুধু একটি warning দিত; Java 16-এ (JEP 396) ডিফল্টে কড়া হলো, আর Java 17-এ (JEP 403) সাধারণ flag দিয়ে পুরোনো ঢিলেঢালা আচরণে ফেরার পথও বন্ধ হলো। এখন কোনো লাইব্রেরি সত্যিই দরকার হলে চালানোর সময় --add-opens java.base/java.lang=ALL-UNNAMED দিতে হয় — এবং সেটা একটি সতর্ক সংকেত, সমাধান নয়।

record আর reflection

পর্ব ২৫-এর record-এর জন্য reflection-এ বিশেষ ব্যবস্থা আছে (Java 16 থেকে): cls.isRecord() আর cls.getRecordComponents(). দ্বিতীয়টি record component-গুলো দেয় হেডারে লেখার ক্রমে — field-এর মতো অনির্দিষ্ট ক্রমে নয়, এটা Javadoc-এর নিশ্চয়তা। প্রতিটি component-এর নাম, টাইপ, annotation আর accessor method পাওয়া যায়। record Point(int x, int y)-এর জন্য লুপ চালিয়ে rc.getName() + ":" + rc.getType().getName() + "=" + rc.getAccessor().invoke(p) ছাপলে আসে x:int=3 আর y:int=4. Jackson-এর মতো লাইব্রেরি ঠিক এভাবেই record থেকে JSON বানায় (পর্ব ৩৯), আর অংশ ৬-এর validator-ও এভাবে কাজ করবে।

৬ · নিজের দুটি mini-framework — test runner আর form validator

এখন সব টুকরো জোড়া দেওয়ার সময়। প্রথমে একটি ছোট্ট JUnit: যে method-এর গায়ে @MyTest আছে, সেগুলো খুঁজে চালাবে আর পাস/ফেল জানাবে। কোড লেখার আগে প্রবাহটা দেখে নিন:

1Class<?> cls = Class.forName("FeeTests");2Method[] ms = cls.getDeclaredMethods();3Arrays.sort(ms, comparing(Method::getName));4for (Method m : ms) {5  if (!m.isAnnotationPresent(MyTest.class)) continue;6  try { m.invoke(cls.getDeclaredConstructor().newInstance());7        print("PASS " + m.getName()); }8  catch (InvocationTargetException e) {9        print("FAIL " + m.getName() + " -> " + e.getCause()); }10}

এবার পুরো প্রোগ্রাম। bKash-ধাঁচের cash-out চার্জ (১.৮৫%) হিসাবের একটি method আর তার তিনটি টেস্ট — একটি ইচ্ছা করে ভুল প্রত্যাশা নিয়ে লেখা:

import java.lang.annotation.*;
import java.lang.reflect.*;
import java.util.*;
@Retention(RetentionPolicy.RUNTIME)
@Target(ElementType.METHOD)
@interface MyTest {}
class FeeTests {
    static double cashOutFee(long amount) {
        if (amount <= 0) throw new IllegalArgumentException("amount must be positive");
        return amount * 185 / 10000.0;                    // 1.85%
    }
    @MyTest void feeFor1000() { check(cashOutFee(1000) == 18.5); }
    @MyTest void zeroAmount() { cashOutFee(0); }
    @MyTest void feeFor200()  { check(cashOutFee(200) == 4.0); }
    void helper() { }                                     // @MyTest নেই
    static void check(boolean ok) { if (!ok) throw new AssertionError("check failed"); }
}
class Main {
    public static void main(String[] args) throws Exception {
        Class<?> cls = Class.forName("FeeTests");
        Method[] methods = cls.getDeclaredMethods();
        Arrays.sort(methods, Comparator.comparing(Method::getName));
        int passed = 0, total = 0;
        for (Method m : methods) {
            if (!m.isAnnotationPresent(MyTest.class)) continue;
            total++;
            try {
                m.invoke(cls.getDeclaredConstructor().newInstance());
                passed++;
                System.out.println("PASS " + m.getName());
            } catch (InvocationTargetException e) {
                System.out.println("FAIL " + m.getName() + " -> " + e.getCause());
            }
        }
        System.out.println(passed + "/" + total + " passed");
    }
}

দ্বিতীয় framework: sign-up form-এর validator

একটি অ্যাপের sign-up form-এ নাম ফাঁকা থাকা চলবে না, মোবাইল নম্বর বাংলাদেশি ফরম্যাটে (01 দিয়ে শুরু, তারপর 3–9, মোট ১১ অঙ্ক), বয়স অন্তত ১৮. প্রতিটি নিয়মের জন্য if-else লেখার বদলে নিয়মগুলো লেবেল হিসেবে ডেটার গায়েই লিখে দেওয়া যায়, আর একটি সাধারণ validator সব record-এর জন্য কাজ করবে। Spring-এর Jakarta Bean Validation (@NotBlank, @Min, @Pattern) ঠিক এই ধারণা:

import java.lang.annotation.*;
import java.lang.reflect.*;
import java.util.*;
@Retention(RetentionPolicy.RUNTIME) @Target(ElementType.RECORD_COMPONENT)
@interface NotBlank {}
@Retention(RetentionPolicy.RUNTIME) @Target(ElementType.RECORD_COMPONENT)
@interface Min { int value(); }
@Retention(RetentionPolicy.RUNTIME) @Target(ElementType.RECORD_COMPONENT)
@interface Regex { String value(); String message() default "invalid format"; }
record SignUp(@NotBlank String name,
              @Regex(value = "01[3-9]\\d{8}", message = "not a BD mobile number") String phone,
              @Min(18) int age) {}
class Main {
    static List<String> validate(Record r) throws ReflectiveOperationException {
        List<String> errors = new ArrayList<>();
        for (RecordComponent c : r.getClass().getRecordComponents()) {
            Object v = c.getAccessor().invoke(r);
            if (c.isAnnotationPresent(NotBlank.class) && v.toString().isBlank())
                errors.add(c.getName() + ": must not be blank");
            if (c.getAnnotation(Regex.class) instanceof Regex rx && !v.toString().matches(rx.value()))
                errors.add(c.getName() + ": " + rx.message());
            if (c.getAnnotation(Min.class) instanceof Min min && (int) v < min.value())
                errors.add(c.getName() + ": must be at least " + min.value());
        }
        return errors;
    }
    public static void main(String[] args) throws Exception {
        System.out.println(validate(new SignUp("Rahim", "01712345678", 22)));
        System.out.println(validate(new SignUp("  ", "1712-345", 15)));
    }
}

একই কৌশলে আরও অনেক কিছু বানানো যায়। পর্ব ২২-এর মাঝপথের প্রজেক্টের CLI টুলে প্রতিটি কমান্ডের জন্য একটি বড় switch ছিল। এর বদলে অংশ ৩-এর @Command(name = "add", minArgs = 2) প্রতিটি method-এর গায়ে লাগিয়ে, শুরুতে reflection দিয়ে একবার সব method পড়ে একটি Map<String, Method> বানালে নতুন কমান্ড যোগ করা মানে শুধু নতুন একটি method লেখা — switch ছোঁয়াই লাগবে না। পর্ব ২২-এ উল্লেখ করা picocli লাইব্রেরি ঠিক এভাবেই কাজ করে।

৭ · আসল framework যা করে — আর compile-time বনাম runtime

আপনার দুটি mini-framework বুঝলে বড় framework-গুলো আর রহস্যময় থাকে না। নিচের কোডগুলো চালানো যাবে না (অনলাইন runner-এ এসব লাইব্রেরি নেই); মডিউল ৭-এ এদের সাথে বিস্তারিত দেখা হবে। এখানে শুধু দেখুন প্রতিটি লেবেলের পেছনে কোন পাঠক কী করে:

// JUnit 5 (পর্ব ৪৭) — আপনার test runner-এর বড় ভাই
class FeeTest {
    @Test void feeFor1000() { assertEquals(18.5, Fees.cashOut(1000)); }
}

// Spring (পর্ব ৫০) — class খুঁজে নিজে object বানায়, নির্ভরতা জুড়ে দেয়
@Component
class PaymentService {
    private final SmsSender sms;
    PaymentService(SmsSender sms) { this.sms = sms; }   // Spring নিজে SmsSender দেয়
}

// Jackson (পর্ব ৩৯) — JSON-এর নাম আর Java-র নাম আলাদা হলে
record UserDto(@JsonProperty("full_name") String fullName, int age) {}

// JPA / Hibernate (পর্ব ৪৯-এর পরে) — class থেকে ডেটাবেস টেবিল
@Entity
class Customer {
    @Id @GeneratedValue private Long id;
    private String phone;
}

• JUnit: Maven/Gradle টেস্ট class-গুলোর নাম দেয়; JUnit reflection দিয়ে @Test-ওয়ালা method খোঁজে, প্রতিটির জন্য নতুন object বানিয়ে ডাকে, exception ধরে রিপোর্ট বানায় — অংশ ৬-এর রানারের মতোই।
• Jackson: UserDto-এর component reflection দিয়ে পড়ে; @JsonProperty থাকলে JSON-এ সেই নাম ব্যবহার করে — {"full_name":"Rahim","age":22}.
• JPA: @Entity দেখে class-টিকে টেবিলের সাথে মেলায়, @Id দেখে primary key চেনে, ডেটাবেস থেকে আসা মান setAccessible দিয়ে private field-এ বসায়।
• Spring: সবচেয়ে বড় কাজটা করে — নিচের stepper-এ দেখুন।

com/shop/PaymentService.class
com/shop/BkashSmsSender.class
com/shop/MoneyUtil.class
নির্দিষ্ট package-এর নিচের সব .class ফাইলের তালিকা

PaymentService   @Component  ✔ bean
BkashSmsSender   @Component  ✔ bean (implements SmsSender)
MoneyUtil        —           ✘ সাধারণ class, Spring ছোঁবে না

PaymentService(SmsSender sms)
  → দরকার: একটি SmsSender
  → কে SmsSender? BkashSmsSender
ক্রম: আগে BkashSmsSender, তারপর PaymentService

sender  = BkashSmsSender-এর constructor.newInstance()
payment = PaymentService-এর constructor.newInstance(sender)
container: { smsSender → sender, paymentService → payment }
আপনার কোডে কোথাও new PaymentService(...) নেই

compile-এর সময় annotation processing — reflection ছাড়াই

সব annotation-এর কাজ চলার সময় হয় না। Java 6 থেকে (JSR 269) javac-এ প্লাগ-ইন লাগানো যায়: annotation processor, যা javax.annotation.processing API দিয়ে compile-এর সময়ই annotation পড়ে নতুন সোর্স ফাইল তৈরি করে বা ভুল ধরে।

• MapStruct: @Mapper interface দেখে Entity থেকে DTO-তে কপি করার আসল Java কোড লিখে দেয় — চলার সময় কোনো reflection নেই।
• Dagger: Google-এর dependency injection লাইব্রেরি, Android-এ খুব প্রচলিত। Spring যে কাজ চালুর সময় reflection দিয়ে করে, Dagger সেটা compile-এর সময় সাধারণ new-ওয়ালা কোড বানিয়ে করে।
• Lombok: @Getter, @Data দেখে getter, equals ইত্যাদি যোগ করে। তবে Lombok নিয়ম মেনে নতুন ফাইল বানায় না; javac-এর ভেতরের API ব্যবহার করে আপনার class-ই বদলে দেয় — ভাবনার প্রশ্ন ৪-এ এই বিতর্ক।

এই পার্থক্য সবচেয়ে বেশি চোখে পড়ে GraalVM native-image-এ (পর্ব ২২-এ উল্লেখ করা)। native-image build-এর সময়ই হিসাব করে কোন class আর method লাগবে, বাকি সব বাদ দেয়। কিন্তু Class.forName(someString)-এর String কী হবে, তা build-এর সময় জানা নেই — তাই reflection-এ ব্যবহৃত class আর member-এর তালিকা আলাদা কনফিগারেশন ফাইলে আগেভাগে বলে দিতে হয়, নাহলে চলার সময় সেগুলো “নেই”। এ কারণেই Spring Boot 3 build-এর সময় অনেক কাজ আগাম সেরে রাখার (AOT) ব্যবস্থা এনেছে, আর Micronaut ও Quarkus-এর মতো নতুন framework শুরু থেকেই compile-time-এর পথে গেছে।

৮ · dynamic proxy, MethodHandle — আর reflection-এর দাম

reflection-এর আরেকটি শক্তিশালী রূপ: চলার সময় একটি interface-এর নকল implementation বানানো, যার প্রতিটি method ডাক একটি জায়গায় এসে জমা হয়। এর নাম dynamic proxy (java.lang.reflect.Proxy). ধরুন একটি PaymentService আছে, আর প্রতিটি পেমেন্টের আগে-পরে লগ লিখতে চান — কিন্তু আসল class-এ হাত না দিয়ে:

interface PaymentService { String pay(String to, long amount); }

class BkashPayment implements PaymentService {
    public String pay(String to, long amount) { return "TX-" + to + "-" + amount; }
}

// main-এর ভেতরে:
PaymentService real = new BkashPayment();
PaymentService logged = (PaymentService) Proxy.newProxyInstance(
        PaymentService.class.getClassLoader(),
        new Class<?>[] { PaymentService.class },
        (proxy, method, params) -> {                       // InvocationHandler
            System.out.println("-> " + method.getName() + Arrays.toString(params));
            Object result = method.invoke(real, params);    // আসল object-এ পাঠানো
            System.out.println("<- " + result);
            return result;
        });
logged.pay("01712345678", 500);

-> pay[01712345678, 500]
<- TX-01712345678-500

(OpenJDK 21-এ চালিয়ে যাচাই করা আউটপুট।) logged দেখতে একটি সাধারণ PaymentService, যে কোড এটা ব্যবহার করে সে পার্থক্য জানেই না। ভেতরে কী ঘটে:

PaymentService s = logged;
s.pay("01712345678", 500);
টাইপ PaymentService — interface অনুযায়ী সাধারণ ডাক

public String pay(String a, long b) {
    return (String) handler.invoke(this, payMethod, new Object[]{a, b});
}
Proxy.newProxyInstance চলার সময় এমন একটি class তৈরি করেছে;
প্রতিটি method একই handler-এ পাঠায় (ধারণাগত রূপ)

method = pay,  params = [01712345678, 500]
print("-> pay[01712345678, 500]")      ← আগে
result = method.invoke(real, params)   ← আসল কাজে পাঠানো
print("<- TX-01712345678-500")         ← পরে

BkashPayment.pay → "TX-01712345678-500"
      ↑ handler → proxy → caller
handler চাইলে ডাক আটকাতে, argument বদলাতে,
সময় মাপতে বা transaction শুরু-শেষ করতে পারত

proxy-র ভেতরের handler যদি নিজেই exception ছোড়ে বা method.invoke থেকে InvocationTargetException পায়, সেটা সাবধানে সামলাতে হয় — সাধারণত getCause() আবার ছুড়ে দিয়ে, যাতে caller আসল exception-টাই পায়, মোড়ক নয়।

MethodHandle — আধুনিক, দ্রুততর বিকল্প

Java 7-এ এসেছে java.lang.invoke package-এর MethodHandle: একটি method-এর সরাসরি “হাতল”, যা খোঁজার সময়েই access যাচাই করে নেয়, ফলে প্রতিটি ডাকে বারবার যাচাই লাগে না, আর JIT একে সাধারণ method ডাকের মতো inline করতে পারে।

MethodHandle mh = MethodHandles.lookup().findVirtual(
        Account.class, "getBalance", MethodType.methodType(long.class));
long bal = (long) mh.invokeExact(account);      // account.getBalance()

পর্ব ৩৪-এর lambda আর পর্ব ০৮-এর String জোড়া যে invokedynamic দিয়ে চলে, তার ভিত্তিও MethodHandle. Java 18 থেকে (JEP 416) Method.invoke নিজেও ভেতরে MethodHandle দিয়ে নতুন করে লেখা হয়েছে। সাধারণ অ্যাপ লেখায় MethodHandle প্রায় লাগে না; লাইব্রেরি আর framework লেখকদের জন্য এটা জানা দরকার।

reflection-এর দাম — কখন এড়িয়ে চলবেন

নিয়মটা সহজ: reflection framework লেখার হাতিয়ার, অ্যাপ লেখার নয়। ব্যবসায়িক কোডে “নাম দেখে method ডাকা”র দরকার মনে হলে আগে ভাবুন — একটি interface আর polymorphism (পর্ব ২০–২১), একটি Map<String, Runnable> বা lambda, অথবা sealed type-এর ওপর switch (পর্ব ২৬) দিয়ে কি একই কাজ হয়? প্রায় সবসময় হয়, আর তখন compiler আবার আপনার পাহারায় ফেরে।

৯ · AI-এর যুগে — reflection-এর শর্টকাট চিনে ফেলা

AI টুল reflection খুব সহজে লিখে ফেলে, আর ঠিক এখানেই বিপদ। কোনো সমস্যায় আটকে গেলে (private field-এ মান বসানো দরকার, অজানা টাইপের object থেকে মান পড়া দরকার) AI প্রায়ই একটি “চতুর” reflection সমাধান দেয়, যা আজ চলে কিন্তু নকশাকে দুর্বল করে আর পরের Java সংস্করণে ভাঙতে পারে। নিজের annotation বানাতে বললে আবার উল্টো সমস্যা — খুব সুন্দর annotation আর processor, শুধু @Retention(RUNTIME) নেই।

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

• reflection কি সত্যিই দরকার, নাকি interface/polymorphism/Map দিয়ে একই কাজ হয়?
• প্রতিটি নিজস্ব annotation-এ @Retention(RetentionPolicy.RUNTIME) (যদি চলার সময় পড়া হয়) আর সঠিক @Target আছে
• InvocationTargetException আলাদা করে ধরা, আর লগে বা আবার ছোড়ায় getCause() ব্যবহার করা হয়েছে
• setAccessible(true) নেই, অথবা থাকলে নিজের কোডের ওপর আর কারণ লেখা আছে; --add-opens-এর ওপর নির্ভরতা নেই
• method/field-এর তালিকা সাজিয়ে বা নাম দিয়ে ব্যবহার করা হয়েছে; ক্রমের ওপর নির্ভরতা নেই
• String-এ লেখা method/class নামের জন্য একটি টেস্ট আছে, যাতে refactor-এ ভাঙলে ধরা পড়ে
• ব্যবহারকারীর ইনপুট থেকে সরাসরি Class.forName বা method ডাকা হচ্ছে না (নিরাপত্তা)