Spring Boot-এর শুরু — object-দের জোড়া লাগানোর দায়িত্ব যখন framework-এর

১ · সমস্যাটা আগে — প্রতিটি class নিজেই new লিখলে কী হয়

ছোট প্রোগ্রামে সব কাজ একটি-দুটি class-এ হয়ে যায়। কিন্তু একটি অনলাইন দোকানের অর্ডার নেওয়ার কথা ভাবুন। OrderService-এর কাজ অর্ডার নেওয়া, কিন্তু টাকা কাটতে তার লাগে একটি PaymentGateway (bKash, Nagad বা কার্ড), গ্রাহককে জানাতে একটি SmsSender, অর্ডার সংরক্ষণে একটি OrderRepository (পর্ব ৪৯-এর JDBC), আর সময় লিখতে একটি Clock (পর্ব ৩৮). অ্যাপ যত বড় হয়, object-রা তত বেশি অন্য object-এর ওপর নির্ভর করে। এই অন্য object-গুলোকে বলে নির্ভরতা বা dependency.

প্রশ্ন হলো, এই নির্ভরতাগুলো কে বানাবে? সবচেয়ে সহজ উত্তর — class নিজেই:

class OrderService {
    private final PaymentGateway gateway = new BkashGateway("merchant-123", "secret-key");
    private final SmsSender sms = new RealSmsSender("https://sms.example.com/api");
    private final OrderRepository repo = new JdbcOrderRepository("jdbc:mysql://prod-db/shop");

    void placeOrder(Order order) { ... }
}

কোডটি চলে। কিন্তু এর ভেতরে তিনটি লুকানো সমস্যা আছে, যা অ্যাপ বড় হলে যন্ত্রণা হয়ে দাঁড়ায়:

এই অবস্থাকে বলে শক্ত বাঁধন বা tight coupling: OrderService শুধু “কোনো একটি পেমেন্ট ব্যবস্থা” নয়, একটি নির্দিষ্ট class, নির্দিষ্ট key আর নির্দিষ্ট ঠিকানার সাথে বাঁধা। পর্ব ২১-এ এর সমাধানের প্রথম অর্ধেক দেখেছেন — interface-এর দিকে প্রোগ্রাম করা, আর নির্ভরতা constructor দিয়ে বাইরে থেকে দেওয়া:

class OrderService {
    private final PaymentGateway gateway;     // interface — কোন implementation, জানে না
    private final SmsSender sms;

    OrderService(PaymentGateway gateway, SmsSender sms) {   // যা লাগবে, বাইরে থেকে আসবে
        this.gateway = gateway;
        this.sms = sms;
    }
}

এখন OrderService পরিষ্কার: তার কী লাগবে, constructor-এর দিকে তাকালেই বোঝা যায়। কিন্তু সমস্যাটা পুরোপুরি যায়নি, শুধু সরে গেছে। কাউকে তো new BkashGateway(...) আর new OrderService(gateway, sms) লিখতেই হবে, ঠিক ক্রমে। দশটি class হলে এটা সহজ; দুইশো class হলে — যেখানে A-র লাগে B আর C, B-র লাগে D, আর D-র লাগে কনফিগারেশন থেকে পড়া একটি URL — এই “জোড়া লাগানোর” কোড নিজেই একটি বড় প্রজেক্ট হয়ে দাঁড়ায়। দ্বিতীয় অর্ধেক সমাধান হলো এই কাজটাও একটি যন্ত্রের হাতে দেওয়া।

২ · Inversion of Control আর Dependency Injection — নিজের হাতে একটি mini container

সাধারণ প্রোগ্রামে নিয়ন্ত্রণ আপনার কোডের হাতে: আপনার main ঠিক করে কখন কোন object বানানো হবে, কখন কোন method ডাকা হবে। লাইব্রেরি (যেমন Math.sqrt) আপনি ডাকেন। Inversion of Control (IoC) মানে এই নিয়ন্ত্রণ উল্টে দেওয়া: object বানানো, জোড়া দেওয়া, কখন কোনটা চালু হবে — এই সিদ্ধান্তগুলো নেয় একটি framework, আর আপনার কোড শুধু ছোট ছোট অংশ দেয়, যাদের framework সময়মতো ডাকে। একে মজা করে বলা হয় “Hollywood নীতি”: don't call us, we'll call you — আমাদের ডাকবেন না, দরকার হলে আমরাই ডাকব।

IoC একটি বড় ধারণা; তার সবচেয়ে প্রচলিত রূপ হলো dependency injection (DI): একটি object নিজের নির্ভরতা নিজে বানায় না বা খুঁজে আনে না, বাইরে থেকে কেউ সেগুলো ঢুকিয়ে (inject করে) দেয়। আর যে যন্ত্র এই কাজটা করে, তাকে বলে IoC container. পর্ব ৪৫-এ দেখেছেন Spring কীভাবে @Component class খুঁজে reflection দিয়ে constructor ডাকে। এবার সেই ধারণা দিয়ে একটি পুরো ছোট container লেখা যাক — কোনো লাইব্রেরি ছাড়া, শুধু JDK দিয়ে। কোড দেখার আগে, container কীভাবে OrderService-এর নির্ভরতা পুনরাবৃত্তি (recursion, পর্ব ১২) দিয়ে খুঁজে বের করে, ধাপে ধাপে দেখুন:

1Object create(Class<?> type) {2  if (singletons.containsKey(type)) return singletons.get(type);3  Class<?> impl = bindings.getOrDefault(type, type);4  Constructor<?> ctor = impl.getDeclaredConstructors()[0];5  for (...) args[i] = create(paramTypes[i]);   // পুনরাবৃত্তি6  Object bean = ctor.newInstance(args);7  singletons.put(type, bean); return bean;8}

এবার পুরো প্রোগ্রাম। interface থেকে implementation-এর “binding” হাতে লেখা, বাকি সব container নিজে বের করে:

import java.lang.reflect.*;
import java.util.*;
interface PaymentGateway { String pay(long amount); }
interface SmsSender { void send(String to, String text); }
class BkashGateway implements PaymentGateway { public String pay(long a) { return "bKash paid " + a; } }
class ConsoleSms implements SmsSender { public void send(String to, String t) { System.out.println("SMS " + to + ": " + t); } }
class OrderService {
    private final PaymentGateway gateway; private final SmsSender sms;
    OrderService(PaymentGateway g, SmsSender s) { gateway = g; sms = s; }
    void placeOrder(String phone, long amount) { sms.send(phone, gateway.pay(amount)); }
}
class MiniContainer {
    private final Map<Class<?>, Class<?>> bindings = new HashMap<>();
    private final Map<Class<?>, Object> singletons = new HashMap<>();
    void bind(Class<?> type, Class<?> impl) { bindings.put(type, impl); }
    <T> T get(Class<T> type) throws ReflectiveOperationException { return type.cast(create(type, "")); }
    private Object create(Class<?> type, String pad) throws ReflectiveOperationException {
        if (singletons.containsKey(type)) { System.out.println(pad + "reuse " + type.getSimpleName()); return singletons.get(type); }
        Class<?> impl = bindings.getOrDefault(type, type);
        System.out.println(pad + "need " + type.getSimpleName() + " -> " + impl.getSimpleName());
        Constructor<?> ctor = impl.getDeclaredConstructors()[0];     // প্রতিটি class-এ constructor একটিই
        Object[] args = new Object[ctor.getParameterCount()];
        for (int i = 0; i < args.length; i++) args[i] = create(ctor.getParameterTypes()[i], pad + "  ");
        Object bean = ctor.newInstance(args);
        singletons.put(type, bean);
        System.out.println(pad + "created " + impl.getSimpleName());
        return bean;
    }
}
class Main {
    public static void main(String[] args) throws Exception {
        var box = new MiniContainer();
        box.bind(PaymentGateway.class, BkashGateway.class);
        box.bind(SmsSender.class, ConsoleSms.class);
        box.get(OrderService.class).placeOrder("01712345678", 1500);
        System.out.println("same sender? " + (box.get(SmsSender.class) == box.get(SmsSender.class)));
    }
}

৩ · Spring-এর মূল ধারণা — ApplicationContext, bean আর stereotype

Spring-এ আপনার mini container-এর নাম ApplicationContext. এর ভেতরে যে object-গুলো থাকে আর যাদের জীবন Spring নিয়ন্ত্রণ করে, তাদের বলে bean. সব object bean নয় — একটি Order record, যা প্রতিটি অনুরোধে নতুন তৈরি হয়, সাধারণ object. bean হলো সেই “সেবাদানকারী” object-গুলো, যারা অ্যাপজুড়ে কাজ করে: service, repository, controller, কনফিগারেশন।

Spring-কে কীভাবে বলবেন কোন class bean হবে? পর্ব ৪৫-এর component scanning: class-এর গায়ে একটি লেবেল। মূল লেবেল @Component, আর তার চারটি “আত্মীয়”, যাদের বলে stereotype annotation:

package com.shop.order;

import org.springframework.stereotype.Service;

@Service
public class OrderService {
    private final PaymentGateway gateway;
    private final SmsSender sms;

    public OrderService(PaymentGateway gateway, SmsSender sms) {   // @Autowired লাগে না
        this.gateway = gateway;
        this.sms = sms;
    }

    public String placeOrder(String phone, long amount) {
        String tx = gateway.pay(amount);
        sms.send(phone, "Order confirmed: " + tx);
        return tx;
    }
}

লক্ষ করুন, @Autowired লেখা নেই। Spring 4.3 থেকে একটি class-এ constructor একটিই থাকলে Spring সেটাকেই নির্ভরতা দেওয়ার পথ ধরে নেয়। এটাই constructor injection, আর আধুনিক Spring-এ এটাই প্রস্তাবিত পথ। OrderService-এর কোড প্রায় সাধারণ Java — শুধু একটি লেবেল আর import. চাইলে Spring ছাড়াই new OrderService(fakeGateway, fakeSms) লিখে টেস্ট করা যায়।

@Configuration আর @Bean — যে class আপনার লেখা নয়

নিজের class-এ @Service লাগানো সহজ। কিন্তু java.time.Clock বা একটি HTTP client লাইব্রেরির class-এর সোর্স আপনার হাতে নেই, সেখানে লেবেল লাগাবেন কীভাবে? তখন একটি কনফিগারেশন class-এ method লিখে বলে দিন, “এই object-টাও bean হবে”:

@Configuration
public class AppConfig {

    @Bean
    public Clock clock() {
        return Clock.system(ZoneId.of("Asia/Dhaka"));       // JDK-র class — আমাদের লেখা নয়
    }

    @Bean
    public HttpClient httpClient() {
        return HttpClient.newBuilder().connectTimeout(Duration.ofSeconds(5)).build();
    }
}

@Bean-ওয়ালা প্রতিটি method-এর ফেরত object Spring container-এ রাখে, method-এর নাম হয় bean-এর নাম (clock, httpClient). এখন যেকোনো service constructor-এ Clock clock চাইলে এটাই পাবে — আর টেস্টে আপনি Clock.fixed(...) দিতে পারবেন, যাতে “আজকের তারিখ”-নির্ভর কোডও নিশ্চিত ফল দেয় (পর্ব ৩৮).

৪ · injection-এর ধরন, scope, lifecycle আর একাধিক implementation

field injection — কেন এড়িয়ে চলবেন

পুরোনো টিউটোরিয়াল আর অনেক AI-লেখা কোডে এমন দেখবেন:

@Service
public class OrderService {
    @Autowired private PaymentGateway gateway;    // field injection — এড়িয়ে চলুন
    @Autowired private SmsSender sms;
}

এটাকে বলে field injection: Spring reflection দিয়ে (পর্ব ৪৫-এর setAccessible) সরাসরি private field-এ মান বসায়। লেখা ছোট, কিন্তু দাম অনেক। field final হতে পারে না, তাই object তৈরির পরে বদলে যাওয়ার সুযোগ থাকে। নির্ভরতা লুকানো — class-এর বাইরে থেকে দেখে বোঝা যায় না কী লাগবে। আর সবচেয়ে বড় কথা: Spring ছাড়া new OrderService() লিখলে দুটি field-ই null, প্রথম method ডাকেই NullPointerException. টেস্টে নকল বসাতে তখন আবার reflection বা পুরো Spring চালু করতে হয়। constructor injection-এ এই তিনটি সমস্যার কোনোটিই নেই। (setter injection আরেকটি পথ — ঐচ্ছিক নির্ভরতার জন্য মাঝে মাঝে কাজে লাগে।)

bean scope — একটি, নাকি প্রতিবার নতুন?

mini container-এ দেখেছেন, একবার বানানো object বারবার দেওয়া হয়। Spring-এ এটাকে বলে bean scope, আর ডিফল্ট হলো singleton — প্রতিটি container-এ একটি bean-এর একটিই object. এজন্য singleton bean-এ অনুরোধ-ভিত্তিক বদলযোগ্য অবস্থা (যেমন “বর্তমান ব্যবহারকারী” একটি field-এ) রাখা বিপজ্জনক: একসাথে হাজার অনুরোধ একই object ব্যবহার করে (পর্ব ৪০-এর race condition). অন্য scope-গুলো ধাপে ধাপে দেখুন:

OrderService a = ctx.getBean(OrderService.class);
OrderService b = ctx.getBean(OrderService.class);
a == b   → true
অ্যাপ চালুর সময় একবার তৈরি, বন্ধ হওয়া পর্যন্ত একই object

@Component @Scope("prototype")
class ReceiptBuilder { ... }

ctx.getBean(ReceiptBuilder.class) == ctx.getBean(ReceiptBuilder.class)
→ false   প্রতিবার নতুন object

@Service class InvoiceService {
    InvoiceService(ReceiptBuilder rb) { ... }   // inject হয় একবারই
}
InvoiceService singleton → ReceiptBuilder-ও কার্যত একটিই
প্রতিবার নতুন চাইলে: ObjectProvider<ReceiptBuilder>.getObject()

অনুরোধ ১ (রহিম)  → CartContext #1
অনুরোধ ২ (করিম)  → CartContext #2
অনুরোধ ১ শেষ     → CartContext #1 ফেলে দেওয়া
session scope হলে: একই ব্যবহারকারীর পুরো session-এ একটি

lifecycle — তৈরি হওয়ার পরে আর বন্ধ হওয়ার আগে

কিছু bean-এর তৈরি হওয়ার পরে একটি প্রস্তুতি লাগে (cache গরম করা, কনফিগারেশন যাচাই), আর অ্যাপ বন্ধের আগে পরিষ্কার করা লাগে (connection বন্ধ)। এর জন্য দুটি annotation, Spring Boot 3-এ jakarta.annotation package থেকে:

import jakarta.annotation.PostConstruct;
import jakarta.annotation.PreDestroy;

@Component
public class TariffCache {
    @PostConstruct
    void load() { System.out.println("loading delivery tariffs"); }   // সব নির্ভরতা inject হওয়ার পরে

    @PreDestroy
    void close() { System.out.println("tariff cache closed"); }      // context বন্ধ হওয়ার আগে
}

ক্রমটা মনে রাখুন: constructor চলে → নির্ভরতা inject হয় → @PostConstruct চলে → bean ব্যবহারের জন্য তৈরি → … → অ্যাপ বন্ধের সময় @PreDestroy. constructor injection-এ নির্ভরতা constructor-এই এসে যায়, তাই সাধারণ প্রস্তুতি constructor-এই করা যায়; @PostConstruct কাজে লাগে যখন কাজটা constructor-এ রাখতে চান না (যেমন ধীর I/O-এর কাজ)।

একটি interface, তিনটি implementation — @Primary আর @Qualifier

দোকানে এখন bKash, Nagad আর কার্ড — তিনটিই PaymentGateway:

@Component("bkash") class BkashGateway implements PaymentGateway { ... }
@Component("nagad") class NagadGateway implements PaymentGateway { ... }
@Component("card")  class CardGateway  implements PaymentGateway { ... }

OrderService(PaymentGateway gateway, ...) চাইলে Spring কোনটা দেবে? সে অনুমান করে না — অ্যাপ চালু হওয়াই বন্ধ হয়ে যায়। Spring Boot এমন একটি বার্তা দেখায় (প্রত্যাশিত আউটপুট, সংক্ষেপে — সংস্করণভেদে শব্দ আলাদা হতে পারে):

***************************
APPLICATION FAILED TO START
***************************

Description:

Parameter 0 of constructor in com.shop.order.OrderService required a single bean, but 3 were found:
	- bkash: defined in file [.../BkashGateway.class]
	- nagad: defined in file [.../NagadGateway.class]
	- card: defined in file [.../CardGateway.class]

Action:

Consider marking one of the beans as @Primary, updating the consumer to accept multiple beans, or using @Qualifier to identify the bean that should be consumed

বার্তাটি নিজেই তিনটি সমাধান বলে দিচ্ছে:

• @Primary: একটির গায়ে লাগালে সেটা ডিফল্ট পছন্দ — যে কেউ শুধু PaymentGateway চাইলে সেটাই পাবে।
• @Qualifier: যে চাইছে, সে নাম দিয়ে নির্দিষ্ট করে: OrderService(@Qualifier("nagad") PaymentGateway gateway, ...). @Qualifier @Primary-এর চেয়ে অগ্রাধিকার পায়।
• সবগুলো একসাথে: List<PaymentGateway> বা Map<String, PaymentGateway> চাইলে Spring তিনটিই দেয়; Map-এ key হলো bean-এর নাম। গ্রাহক চেকআউটে যেটা বাছবেন, gateways.get("bkash") দিয়ে সেটা — পর্ব ৪৫-এর অনুশীলনে বলা “reflection নয়, Map” সমাধানের Spring রূপ।

৫ · Spring Boot — Initializr, starter, auto-configuration আর এক লাইনে চালু

Spring Framework নিজে শক্তিশালী, কিন্তু আগে একটি web অ্যাপ দাঁড় করাতেই অনেক কাজ লাগত: ঠিক সংস্করণের দশটি লাইব্রেরি বাছাই, XML বা Java-তে কনফিগারেশন, আলাদা Tomcat সার্ভার ইনস্টল করে তাতে WAR ফাইল deploy. Spring Boot (২০১৪) এই প্রস্তুতির কাজটা সরিয়ে দিল। তার দর্শন পর্ব ৪৫-এ দেখা convention over configuration: যুক্তিসংগত ডিফল্ট আগে থেকেই ঠিক করা, আপনি শুধু ব্যতিক্রমটুকু লিখবেন।

প্রজেক্ট তৈরি — start.spring.io

Spring Initializr (start.spring.io) একটি ওয়েবসাইট, যেখানে কয়েকটি ঘর পূরণ করলে একটি তৈরি প্রজেক্টের zip পাওয়া যায়: build টুল (Maven বা Gradle — পর্ব ৪৬), ভাষা (Java), Spring Boot সংস্করণ, group (com.shop), artifact (shop), Java সংস্করণ (21), আর dependency — শুরুতে “Spring Web” যথেষ্ট। IntelliJ IDEA আর VS Code-এর Spring extension-এর ভেতরেও একই Initializr আছে। zip খুললে পাবেন:

shop/
├── mvnw, mvnw.cmd              ← Maven Wrapper: Maven ইনস্টল ছাড়াই build
├── pom.xml                     ← dependency আর Spring Boot সংস্করণ
└── src/
    ├── main/java/com/shop/ShopApplication.java
    ├── main/resources/application.properties
    └── test/java/com/shop/ShopApplicationTests.java

pom.xml-এ সবচেয়ে গুরুত্বপূর্ণ অংশ একটি starter:

<parent>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-parent</artifactId>
    <version>3.x.y</version>   <!-- Initializr যে সংস্করণ বসায় -->
</parent>

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-web</artifactId>   <!-- সংস্করণ লিখতে হয় না -->
</dependency>

starter নিজে প্রায় কোনো কোড নয় — এটা একটি “বান্ডিল”, যা একসাথে-কাজ-করে-এমন লাইব্রেরিগুলোর একটি পরীক্ষিত সেট টেনে আনে। spring-boot-starter-web আনে Spring MVC, JSON-এর জন্য Jackson (পর্ব ৩৯), embedded Tomcat আর logging. parent POM প্রতিটি লাইব্রেরির সংস্করণ ঠিক করে রাখে, তাই আপনাকে আলাদা সংস্করণ মেলাতে হয় না। অন্য প্রচলিত starter: spring-boot-starter-data-jpa (ডেটাবেস), spring-boot-starter-validation, spring-boot-starter-test (JUnit 5 আর Mockito — পর্ব ৪৭), spring-boot-starter-actuator.

main class আর @SpringBootApplication

package com.shop;

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;

@SpringBootApplication
public class ShopApplication {
    public static void main(String[] args) {
        SpringApplication.run(ShopApplication.class, args);
    }
}

পুরো অ্যাপের শুরু এই কয়েকটি লাইন। @SpringBootApplication আসলে তিনটি annotation-এর সংক্ষেপ:

• @SpringBootConfiguration — যা নিজে একটি @Configuration; তাই এই class-এও @Bean method লেখা যায়।
• @EnableAutoConfiguration — auto-configuration চালু করে (নিচে)।
• @ComponentScan — এই class-এর package (com.shop) আর তার নিচের সব package-এ @Component খোঁজে। তাই main class সবসময় সবচেয়ে ওপরের package-এ রাখুন; com.other-এ রাখা একটি @Service Spring খুঁজেই পাবে না।

auto-configuration — “আপনার classpath দেখে বুঝে নিচ্ছি”

auto-configuration Spring Boot-এর আসল জাদু, আর এটাও শুধু শর্তসাপেক্ষ @Configuration class. Spring Boot-এর ভেতরে শত শত এমন class আছে, প্রতিটির গায়ে শর্ত:

@AutoConfiguration
@ConditionalOnClass(DataSource.class)                    // classpath-এ JDBC আছে?
public class DataSourceAutoConfiguration {

    @Bean
    @ConditionalOnMissingBean                            // আপনি নিজে DataSource দেননি?
    DataSource dataSource(DataSourceProperties props) {  // তাহলে properties থেকে আমরা বানাই
        ...
    }
}

@ConditionalOnClass বলে “এই class classpath-এ থাকলে তবেই”। @ConditionalOnMissingBean বলে “আপনি নিজে এমন bean না দিয়ে থাকলে তবেই” — তাই আপনার নিজের @Bean DataSource থাকলে Spring Boot সরে দাঁড়ায়। @ConditionalOnProperty একটি property-র মান দেখে। ফলাফল: pom.xml-এ web starter যোগ করলেই Tomcat চালু হয়, JPA starter আর একটি ডেটাবেস driver যোগ করলেই connection pool তৈরি হয় — কোনো কনফিগারেশন কোড না লিখে। কোন auto-configuration কেন চলল বা চলল না, দেখতে চাইলে --debug দিয়ে চালান; Spring Boot একটি “conditions evaluation report” ছাপে।

এবার সব জোড়া দিয়ে দেখুন SpringApplication.run চালালে ভেতরে কী কী ঘটে:

SpringApplication.run(ShopApplication.class, args)
→ classpath-এ Spring MVC আছে → web ধরনের ApplicationContext
→ banner আর প্রথম log লাইন
Starting ShopApplication using Java 21 ...

com.shop.order.OrderService       @Service     ✔
com.shop.pay.BkashGateway         @Component   ✔
com.shop.sms.FakeSmsSender        @Component @Profile("dev")  (শর্ত পরে)
com.shop.AppConfig                @Configuration ✔
এখনো কোনো object নেই — শুধু bean-এর “সংজ্ঞা” (recipe)

application.properties          shop.vat-rate=0.15
application-dev.properties      (profile dev সক্রিয় হলে)
environment variable            SHOP_SMS_TOKEN=****
command line                    --server.port=9090
একই key কয়েক জায়গায় থাকলে বাইরেরটা জেতে (অংশ ৬)

TomcatServletWebServer...   @ConditionalOnClass(Tomcat)    ✔ চালু
JacksonAutoConfiguration    @ConditionalOnClass(ObjectMapper) ✔ চালু
DataSourceAutoConfiguration @ConditionalOnClass(DataSource) ✘ JDBC নেই
আপনার নিজের bean থাকলে @ConditionalOnMissingBean সরে দাঁড়ায়

clock            ← নির্ভরতা নেই        → আগে
bkash, smsSender ← নির্ভরতা নেই        → আগে
orderService     ← (bkash, smsSender)  → পরে
ঠিক mini container-এর মতো — পাতা আগে, গোড়া পরে

new OrderService(bkash, smsSender)   ← constructor injection
@PostConstruct TariffCache.load()
proxy বসানো (যেমন @Transactional থাকলে)
কোনো নির্ভরতা না পেলে এখানেই APPLICATION FAILED TO START

Tomcat started on port 8080 (http) with context path '/'
Started ShopApplication in 2.1 seconds (process running for 2.6)
প্রত্যাশিত আউটপুট (সংক্ষেপে) — সংস্করণভেদে আলাদা
এখন http://localhost:8080 অনুরোধ নিতে তৈরি

চালানো আর প্যাকেজ করা

# development-এর সময় চালানো (Windows-এ: mvnw.cmd spring-boot:run)
./mvnw spring-boot:run

# একটি চালানো-যায়-এমন jar বানানো, টেস্টসহ
./mvnw package

# সার্ভারে শুধু JDK লাগে — Tomcat আলাদা লাগে না
java -jar target/shop-0.0.1-SNAPSHOT.jar --server.port=9090

./mvnw package একটি executable jar বানায় (অনেকে বলেন “fat jar”) — আপনার কোড, সব লাইব্রেরি আর embedded Tomcat একটি ফাইলে। এই ফাইল যেকোনো মেশিনে, Docker container-এ বা ক্লাউডে একই কমান্ডে চলে। embedded server-এর এই ধারণাই Spring Boot-কে microservice যুগের স্বাভাবিক পছন্দ বানিয়েছে।

৬ · কনফিগারেশন — properties, profile আর গোপন তথ্য কোডের বাইরে

অংশ ১-এর তৃতীয় সমস্যা ছিল কনফিগারেশন কোডে বন্দি। Spring Boot-এ মানগুলো থাকে application.properties-এ (অথবা একই কাজের YAML সংস্করণ application.yml-এ):

spring.application.name=shop
server.port=8080

# আমাদের নিজের key — "shop." দিয়ে শুরু, যাতে Spring-এর key-এর সাথে না মেশে
shop.vat-rate=0.15
shop.sms.gateway-url=https://sms.example.com/api
shop.sms.sender-id=MyShop
shop.sms.token=${SHOP_SMS_TOKEN}

logging.level.com.shop=DEBUG

shop:
  vat-rate: 0.15
  sms:
    gateway-url: https://sms.example.com/api
    sender-id: MyShop

মান পড়ার দুটি পথ। ছোট, একক মানের জন্য @Value:

@Service
public class PriceService {
    private final BigDecimal vatRate;

    public PriceService(@Value("${shop.vat-rate}") BigDecimal vatRate) {
        this.vatRate = vatRate;
    }
}

অনেকগুলো সম্পর্কিত মানের জন্য ভালো পথ @ConfigurationProperties — একটি record-এ সব মান টাইপসহ (পর্ব ২৫):

@ConfigurationProperties(prefix = "shop.sms")
public record SmsProperties(URI gatewayUrl, String senderId, String token) { }

// main class-এ একবার:
@SpringBootApplication
@ConfigurationPropertiesScan
public class ShopApplication { ... }

Spring Boot shop.sms.gateway-url-কে gatewayUrl-এ মিলিয়ে নেয় (kebab-case থেকে camelCase), String-কে URI-তে রূপান্তর করে, আর record-এর constructor দিয়ে object বানায়। ভুল ফরম্যাটের মান দিলে অ্যাপ চালুর সময়েই ধরা পড়ে, প্রথম SMS পাঠানোর সময় নয়। এখন যেকোনো bean constructor-এ SmsProperties props চাইতে পারে। @Value-এর তুলনায় সুবিধা: টাইপ-যাচাই, এক জায়গায় সব মান, IDE-তে auto-complete, আর টেস্টে new SmsProperties(...) লিখেই নকল কনফিগারেশন।

গোপন তথ্য কখনো কোডে নয়

ওপরের shop.sms.token=${SHOP_SMS_TOKEN} লাইনটি খেয়াল করুন। আসল token properties ফাইলেও নেই; ${...} বলে “এই নামের environment variable থেকে নাও”। Spring Boot আরও এক ধাপ সহজ করে: environment variable SHOP_SMS_TOKEN থাকলে সেটা সরাসরি shop.sms.token-এর মান হিসেবেও ধরা হয় — বড় হাতের অক্ষর, ডট-এর জায়গায় underscore (একে বলে relaxed binding). অগ্রাধিকারের মোটামুটি নিয়ম: command-line argument > environment variable > profile-এর ফাইল > application.properties. তাই একই jar dev মেশিনে, টেস্ট সার্ভারে আর আসল সার্ভারে আলাদা মানে চলে — build একবারই।

profile — একই কোড, আলাদা পরিবেশ

development-এ প্রতিবার সত্যিকারের SMS পাঠানো অপচয়, আর টাকাও লাগে। profile দিয়ে বলা যায়, কোন পরিবেশে কোন bean:

@Component
@Profile("dev")
class FakeSmsSender implements SmsSender {
    private static final Logger log = LoggerFactory.getLogger(FakeSmsSender.class);
    public void send(String to, String text) { log.info("[FAKE SMS] {} : {}", to, text); }
}

@Component
@Profile("prod")
class RealSmsSender implements SmsSender {
    private final SmsProperties props;
    private final HttpClient http;
    RealSmsSender(SmsProperties props, HttpClient http) { this.props = props; this.http = http; }
    public void send(String to, String text) { /* props.gatewayUrl()-এ HTTP POST */ }
}

@Service class NotificationService {
    NotificationService(SmsSender sms) { ... }
}
FakeSmsSender  @Profile("dev")
RealSmsSender  @Profile("prod")

The following 1 profile is active: "dev"
application.properties + application-dev.properties
SmsSender → FakeSmsSender
INFO  [FAKE SMS] 01711111111 : Order confirmed

SPRING_PROFILES_ACTIVE=prod
SHOP_SMS_TOKEN=****            ← secret, কোডে নেই
java -jar shop.jar
SmsSender → RealSmsSender(SmsProperties, HttpClient)

No active profile set, falling back to 1 default profile: "default"
APPLICATION FAILED TO START
Parameter 0 of constructor in com.shop.NotificationService
required a bean of type 'com.shop.SmsSender' that could not be found.

Spring Boot যা স্বয়ংক্রিয়ভাবে করে, তার মূল যুক্তি সাধারণ Java-তে চালিয়ে দেখুন। প্রথমে একটি class যে নিজেই new করে, তারপর constructor injection-এর class — যাকে “profile” অনুযায়ী আলাদা implementation দেওয়া হয়, আর টেস্টে নিজের হাতে নকল:

import java.util.*;
interface SmsSender { String send(String to, String text); }
record RealSmsSender(String url) implements SmsSender {
    public String send(String to, String text) { return "POST " + url + " to=" + to; }
}
class FakeSmsSender implements SmsSender {
    final List<String> sent = new ArrayList<>();
    public String send(String to, String text) { sent.add(to + " " + text); return "fake, saved " + to; }
}
class HardWiredNotifier {                       // নিজেই new করে — বদলানো যায় না
    private final SmsSender sms = new RealSmsSender("https://sms.example.com/api");
    String welcome(String phone) { return sms.send(phone, "Welcome"); }
}
class NotificationService {                     // বাইরে থেকে পায় — constructor injection
    private final SmsSender sms;
    NotificationService(SmsSender sms) { this.sms = sms; }
    String welcome(String phone) { return sms.send(phone, "Welcome"); }
}
class Main {
    static SmsSender smsFor(String profile, Map<String, String> config) {
        return switch (profile) {
            case "prod" -> new RealSmsSender(config.get("sms.gateway.url"));
            default -> new FakeSmsSender();
        };
    }
    public static void main(String[] args) {
        var config = Map.of("sms.gateway.url", "https://sms.example.com/api");
        System.out.println("hard-wired: " + new HardWiredNotifier().welcome("01711111111"));
        for (String profile : List.of("dev", "prod"))
            System.out.println(profile + ": " + new NotificationService(smsFor(profile, config)).welcome("01711111111"));
        var fake = new FakeSmsSender();             // টেস্টে নিজের হাতে নকল দেওয়া
        new NotificationService(fake).welcome("01822222222");
        System.out.println("test saw: " + fake.sent);
    }
}

৭ · logging, প্রথম endpoint, Actuator, DevTools আর virtual thread

logging — println নয়

সার্ভারে চলা অ্যাপে System.out.println যথেষ্ট নয়: কখন লেখা হলো, কোন class থেকে, কতটা গুরুত্বপূর্ণ — কিছুই থাকে না, আর বন্ধও করা যায় না। Spring Boot-এ ডিফল্টে SLF4J (লেখার API) আর Logback (আসল লেখক) সাজানো থাকে:

private static final Logger log = LoggerFactory.getLogger(OrderService.class);

log.debug("checking stock for {}", productId);          // খুঁটিনাটি — dev-এ
log.info("order {} placed, amount {}", orderId, amount); // স্বাভাবিক ঘটনা
log.warn("SMS gateway slow: {} ms", elapsed);            // সন্দেহজনক
log.error("payment failed for order {}", orderId, ex);   // ভুল — exception সহ

{} জায়গাধারী: লেখাটা আসলেই ছাপা হলে তবেই String জোড়া হয়, তাই বন্ধ থাকা debug log প্রায় বিনা খরচে। log level-এর ক্রম TRACE < DEBUG < INFO < WARN < ERROR; Spring Boot-এর ডিফল্ট INFO, মানে debug আর trace ছাপা হয় না। logging.level.com.shop=DEBUG দিয়ে শুধু নিজের package-এর জন্য বাড়ানো যায়। log-এ কখনো পাসওয়ার্ড, পুরো কার্ড নম্বর বা OTP লিখবেন না।

প্রথম endpoint — একটি ঝলক

@RestController
public class HelloController {
    @GetMapping("/hello")
    public String hello() {
        return "Assalamu Alaikum from Spring Boot!";
    }
}

curl http://localhost:8080/hello
# প্রত্যাশিত আউটপুট: Assalamu Alaikum from Spring Boot!

@RestController একটি stereotype (তাই স্ক্যানে ধরা পড়ে), আর @GetMapping("/hello") বলে এই URL-এ GET অনুরোধ এলে method-টি চলবে, ফেরত মান সরাসরি উত্তর হিসেবে যাবে। record ফেরত দিলে Jackson সেটাকে JSON বানায়। URL-এর ভেতরের মান পড়া, POST-এ JSON নেওয়া, যাচাই, ভুলের উত্তর, JPA দিয়ে ডেটাবেস — এসব পুরো পর্ব ৫১-এর বিষয়।

Actuator আর DevTools

Actuator starter যোগ করলে অ্যাপ নিজের স্বাস্থ্যের খবর দিতে পারে: /actuator/health-এ গেলে উত্তর {"status":"UP"}. ডেটাবেস বা disk-এর মতো নির্ভরতা খারাপ হলে সেটা DOWN হয়। Kubernetes, load balancer বা monitoring টুল এই URL দেখে বোঝে অ্যাপটি অনুরোধ নিতে প্রস্তুত কি না। নিরাপত্তার কারণে HTTP দিয়ে ডিফল্টে মূলত শুধু health খোলা থাকে; বাকি endpoint (metrics, env) খুলতে আলাদা property লাগে — আর সেগুলো সাধারণ ব্যবহারকারীর কাছে খোলা রাখা উচিত নয়।

DevTools (spring-boot-devtools) development-এর আরাম: কোড বদলে compile করলে অ্যাপ নিজে থেকেই দ্রুত restart হয়, template-এর cache বন্ধ থাকে। java -jar দিয়ে পুরো প্যাকেজ করা অ্যাপ চালালে DevTools নিজেই বন্ধ হয়ে যায়, তবু এটা শুধু development-এর dependency হিসেবে রাখাই নিয়ম।

virtual thread — একটি লাইনের সুইচ

embedded Tomcat ডিফল্টে প্রতিটি অনুরোধের জন্য একটি platform thread ব্যবহার করে (thread-per-request), আর thread pool-এর আকার সীমিত। পর্ব ৪২-এ দেখেছেন, virtual thread খুব হালকা, তাই ডেটাবেস বা SMS gateway-র উত্তরের অপেক্ষায় বসে থাকা হাজারো অনুরোধ একসাথে সামলানো যায়। Spring Boot 3.2 থেকে, Java 21-এ, শুধু একটি property:

spring.threads.virtual.enabled=true

এতে Tomcat অনুরোধ সামলাতে virtual thread ব্যবহার করে, আর Spring-এর কিছু অন্য executor-ও। কোড একই থাকে — সাধারণ blocking স্টাইল। তবে পর্ব ৪২-এর সতর্কতা এখানেও খাটে: CPU-ভারী কাজ দ্রুত হয় না, আর ডেটাবেস connection pool-এর আকার এখনো আসল সীমা।

৮ · Spring Boot 3, jakarta.* আর কখন Spring বেশি ভারী

Spring Boot 3.0 (২০২২-এর শেষে) দুটি বড় বদল আনে, যা পুরোনো কোড আর AI-এর উত্তর পড়ার সময় জানা জরুরি। এই পর্বের কোড Spring Boot 3.x ধরে লেখা; পরের সংস্করণে কিছু starter-এর নাম বা ডিফল্ট বদলাতে পারে — সন্দেহ হলে start.spring.io যা তৈরি করে আর অফিসিয়াল ডকুমেন্টেশন, সেটাই মানুন।

• Java 17 ন্যূনতম। Spring Boot 3 Java 17 বা নতুন ছাড়া চলে না। Java 21 ব্যবহার করলে virtual thread-এর সুবিধাও পাবেন।
• javax.* থেকে jakarta.*. Java EE-র API-গুলো (persistence, validation, servlet, annotation) Eclipse Foundation-এ গিয়ে Jakarta EE নামে চলে, আর Jakarta EE 9 থেকে তাদের package-এর নাম javax. থেকে jakarta. হয়েছে। Spring Boot 3 নতুন নাম ব্যবহার করে: jakarta.persistence.Entity, jakarta.validation.constraints.NotBlank, jakarta.servlet.http.HttpServletRequest, jakarta.annotation.PostConstruct.

Boot 3 প্রজেক্টে পুরোনো import javax.persistence.Entity; লিখলে (আর পুরোনো লাইব্রেরি classpath-এ না থাকলে) javac সাধারণ একটি বার্তা দেয় (OpenJDK 21-এ যাচাই করা, ফাইলের নাম বদলানো):

Customer.java:1: error: package javax.persistence does not exist
import javax.persistence.Entity;
                        ^
Customer.java:3: error: cannot find symbol
@Entity
 ^
  symbol: class Entity
2 errors

Spring কখন বেশি ভারী

Spring Boot-এর চালুর সময় স্ক্যান, reflection আর proxy তৈরিতে কিছু সময় আর মেমরি লাগে — একটি সাধারণ অ্যাপে কয়েক সেকেন্ড আর কয়েকশো MB পর্যন্ত। দীর্ঘ সময় চলা সার্ভারে এটা নগণ্য। কিন্তু কিছু জায়গায় এটা ভাবার বিষয়:

• ছোট CLI টুল বা একটি ফাইল প্রসেস করার script: পর্ব ২২-এর মতো সাধারণ Java, প্রয়োজনে picocli — পুরো container লাগে না।
• serverless আর বারবার চালু-বন্ধ হওয়া container: চালুর প্রতিটি সেকেন্ড খরচ। এখানে Quarkus, Micronaut বা Helidon-এর মতো framework নজর কাড়ে — এরা অনেক কাজ build-এর সময় সেরে রাখে আর GraalVM native-image-এর সাথে খুব দ্রুত চালু হয়। Spring Boot নিজেও AOT আর native-image সমর্থন এনেছে।
• শেখার শুরুতে: Spring অনেক কিছু লুকিয়ে রাখে। আগে সাধারণ Java-তে DI, JDBC, HTTP বুঝে তারপর Spring — যেভাবে এই কোর্স এগিয়েছে — ডিবাগ করার শক্তি দেয়।

তবু বড় ব্যবসায়িক অ্যাপ, ব্যাংক, টেলিকম, ই-কমার্স আর enterprise-এর ব্যাকএন্ডে Spring Boot আজও সবচেয়ে প্রচলিত Java পছন্দগুলোর একটি — তার বিশাল ইকোসিস্টেম (security, data, messaging, cloud) আর দীর্ঘ সময়ের স্থিতিশীলতার কারণে।

৯ · AI-এর যুগে — পুরোনো আর বানানো Spring কোড চিনে ফেলা

Spring নিয়ে ইন্টারনেটে প্রায় বিশ বছরের লেখা আছে — XML কনফিগারেশন, Spring Boot 1 আর 2, field injection-এর যুগ। AI এই সব লেখা থেকে শিখেছে, তাই তার উত্তরে প্রায়ই নতুন আর পুরোনো মিশে যায়। কোড compile হলেও ভুল সংস্করণের ধারণা থাকতে পারে, আর কখনো AI এমন property বা annotation লেখে, যার অস্তিত্বই নেই — Spring Boot অজানা property সাধারণত নীরবে উপেক্ষা করে, তাই কিছুই ঘটে না, ভুলও ধরা পড়ে না।

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

• সব নির্ভরতা constructor-এ, field final; কোনো @Autowired private field নেই
• import-গুলো এক প্রজন্মের: Boot 3 হলে jakarta.*, কোথাও javax.persistence/javax.validation নেই
• প্রতিটি অচেনা property আর annotation অফিসিয়াল ডকুমেন্টেশনে খুঁজে পাওয়া গেছে
• কোনো secret কোডে বা commit করা ফাইলে নেই
• একই interface-এর একাধিক bean থাকলে বাছাই স্পষ্ট (@Primary/@Qualifier/@Profile)
• singleton bean-এ অনুরোধভিত্তিক বদলযোগ্য field নেই
• অ্যাপ সত্যিই চালু করে দেখা হয়েছে, আর context চালু হওয়ার একটি টেস্ট আছে