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

Spring Boot Project in native build using GraalVM Native Image Build for Gradle Project

Spring Boot 3.x এবং GraalVM Native Image ব্যবহারের জন্য Gradle Native Build Tools Plugin ব্যবহার করা সবচেয়ে সহজ উপায়। আপনার প্রজেক্টে Native Image বিল্ড করার জন্য ধাপগুলো নিচে দেওয়া হলো:


🛠️ প্রাথমিক প্রস্তুতি

  1. GraalVM 21 ইনস্টল: আপনার সিস্টেমে GraalVM 21 (বা GraalVM-এর Java 21 ভিত্তিক সংস্করণ) ইনস্টল করা থাকতে হবে।
  2. native-image টুল ইনস্টল: GraalVM-এর native-image টুলটি ইনস্টল করা নিশ্চিত করুন। GraalVM-এর আধুনিক সংস্করণগুলোতে সাধারণত এটি ডিফল্টভাবে থাকে, তবে প্রয়োজন হলে:
    gu install native-image
    
  3. JAVA_HOME সেটআপ: আপনার এনভায়রনমেন্ট ভেরিয়েবল JAVA_HOME যেন GraalVM 21-এর দিকে নির্দেশ করে তা নিশ্চিত করুন।

⚙️ build.gradle কনফিগারেশন

আপনার build.gradle ফাইলটি আপডেট করতে হবে:

1. plugins ব্লক আপডেট

org.graalvm.buildtools.native প্লাগইনটি যুক্ত করুন। এটি Spring Boot-এর Native Support-এর জন্য প্রয়োজনীয়।

plugins {
    id 'org.springframework.boot' version '3.4.3'
    id 'io.spring.dependency-management' version '1.1.5'
    // ... অন্যান্য প্লাগইন 
    id 'org.graalvm.buildtools.native' version '0.10.2' // সংস্করণ 3.4.3 এর সাথে সামঞ্জস্যপূর্ণ
    id 'java'
}

2. dependencies কনফিগারেশন

Native Image-এর জন্য প্রয়োজনীয় GraalVM Native Support ডিপেন্ডেন্সিটি যুক্ত করুন। Spring Initializr থেকে প্রজেক্ট তৈরি করলে এটি স্বয়ংক্রিয়ভাবে যুক্ত হয়ে যায়।

dependencies {
    implementation 'org.springframework.boot:spring-boot-starter'
    // ... অন্যান্য ডিপেন্ডেন্সি
// GraalVM Native Support - সাধারণত 'developmentOnly' কনফিগারেশনে থাকে
developmentOnly 'org.springframework.boot:spring-boot-starter-data-jpa' // উদাহরণের জন্য
developmentOnly 'org.springframework.boot:spring-boot-starter-web' // উদাহরণের জন্য 

// Native Build Tools এর জন্য আলাদা কোনো নির্ভরতা যোগ করার প্রয়োজন নেই, 
// কারণ এটি প্লাগইন হিসেবে উপরে যুক্ত করা হয়েছে। 

}

3. graalvmNative কনফিগারেশন (ঐচ্ছিক)

আপনি যদি Native Image বিল্ডের জন্য অতিরিক্ত আর্গুমেন্ট (যেমন মেমরি সেটিংস, verbose আউটপুট ইত্যাদি) দিতে চান, তবে এটি ব্যবহার করতে পারেন:

graalvmNative {
    binaries {
        main {
            // Native Image বিল্ড করার সময় অতিরিক্ত আর্গুমেন্ট যোগ করা যেতে পারে
            buildArgs.add('-H:Name=<আপনার-এক্সিকিউটেবল-নাম>') 
            buildArgs.add('--verbose')
            // ... অন্যান্য GraalVM আর্গুমেন্ট
        }
    }
}

🚀 Native Image বিল্ড করা

সব কনফিগারেশন ঠিক থাকলে, আপনার অ্যাপ্লিকেশনটির Native Executable বিল্ড করতে নিম্নলিখিত Gradle টাস্কটি চালান:

./gradlew nativeCompile

ফলাফল

  • বিল্ড সফল হলে, আপনার Native Executable ফাইলটি সাধারণত build/native/nativeCompile ডিরেক্টরিতে তৈরি হবে।
  • আপনি এটিকে সরাসরি চালাতে পারবেন (JVM ছাড়াই):
    ./build/native/nativeCompile/<আপনার-এক্সিকিউটেবল-নাম>
    

এছাড়াও, বিল্ড করার পর অ্যাপ্লিকেশনটি সরাসরি চালানোর জন্য nativeRun টাস্ক ব্যবহার করতে পারেন:

./gradlew nativeRun

মন্তব্যসমূহ

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

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

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

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

Introduction এই ভিডিওর নির্দিষ্ট অংশে জাভা ল্যাঙ্গুয়েজ আর্কিটেক্ট ব্রায়ান গোয়েটজ (Brian Goetz) আলোচনা করেছেন কীভাবে জাভার নতুন ফিচারগুলো তৈরি হয় এবং এতে সাধারণ ডেভেলপারদের মতামতের গুরুত্ব কতটুকু। বিশেষ করে Structured Concurrency -এর মতো জটিল ফিচারগুলো কেন বারবার 'Preview' অবস্থায় থাকে এবং কীভাবে কমিউনিটির ফিডব্যাক সেই ফিচারগুলোকে আরও নিখুঁত করতে সাহায্য করে, তা এখানে সহজভাবে বোঝানো হয়েছে। ১. ভালো ফিডব্যাক আসলে কী? ভিডিও রেফারেন্স: [ 34:53 ] ব্রায়ান গোয়েটজ বলছেন যে, জাভা টিম যখন কোনো নতুন ফিচারের খসড়া (Draft) বা প্রস্তাব (JEP) প্রকাশ করে, তখন তারা এমন কিছু জানতে চায় যা তারা নিজেরা আগে ভাবেনি। বিস্তারিত: একজন ডেভেলপার হিসেবে আমরা যখন কোনো নতুন ফিচার দেখি, আমাদের প্রথম প্রতিক্রিয়া হয় সেটার Syntax বা লেখার ধরন নিয়ে। কিন্তু ব্রায়ানের মতে, "এই লেখাটা কেন এমন হলো?" বা "এটা কোটলিন বা স্কালা-র মতো কেন নয়?"—এই ধরনের ফিডব্যাক খুব একটা কাজে আসে না। আসল দামী ফিডব্যাক হলো সেইটা, যা নতুন কোনো বাস্তব সমস্যা (Edge Case) তুলে ধরে। আমার চিন্তা: আপনি যদি কেবল দ...

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 এ। তাদের মধ্যে ...