Java EE / Jakarta EE و تفاوتش با SpringJava EE / Jakarta EE and How It Differs from Spring

اگر چند سال با Spring Boot کار کرده باشی، یک روز به پروژه‌ای می‌خوری که به‌جای @RestController کلاسی با @Path دارد، به‌جای @Service یک @Stateless، و به‌جای java -jar app.jar یک فایل .ear را روی چیزی به اسم WildFly «deploy» می‌کند. یا در مصاحبه می‌پرسند «فرق Jakarta EE با Spring چیست؟» و اگر بگویی «یکی قدیمی است و یکی جدید»، مصاحبه‌گر می‌فهمد فقط یک لایه از داستان را می‌شناسی. این فصل همان شکاف را پر می‌کند: از معنی کلمه‌ی «specification» شروع می‌کنیم و تا جایی می‌رویم که بتوانی درباره‌ی مهاجرت یک سیستم legacy تصمیم بگیری و از آن دفاع کنی.

فصل‌های دیگر روی Spring (spring-core، spring-boot-web، spring-data-tx)، jpa-hibernate، microservices-distributed و ms-security عمیق شده‌اند؛ اینجا آن‌ها را تکرار نمی‌کنیم و فقط روی چیزی تمرکز می‌کنیم که جای دیگری پوشش داده نشده: خودِ استاندارد.

۱. آنالوژی: پریز برق در برابر یک برند لوازم خانگی

تقریباً هر تفاوت دیگری از همین یکی بیرون می‌آید: چرا Jakarta EE کندتر تغییر می‌کند، چرا Spring سریع‌تر feature می‌دهد، و چرا در بانک و بیمه هنوز application server می‌بینی ولی در استارتاپ‌ها تقریباً همه‌جا Spring Boot است.

۲. تاریخ و نام‌ها

اول واژه‌ها. Java SE یعنی خود زبان و کتابخانه‌ی پایه که با JDK می‌گیری؛ Java EE مجموعه‌ای از API‌های اضافه برای کارهای سازمانی است (HTTP، تراکنش، پیام، persistence، امنیت) که روی Java SE سوار می‌شود. JCP فرایند رسمی نوشتن استانداردهاست و خروجی هر پروژه یک JSR. spec سندی است که رفتار یک API را تعریف می‌کند، RI پیاده‌سازی مرجع (مثل Jersey برای JAX-RS)، و TCK مجموعه‌ی عظیم تستی که پاس کردنش حق ادعای «certified» می‌دهد — همین آخری «استاندارد» را از «ادعا» جدا می‌کند.

J2EE (۱۹۹۹–۲۰۰۳) نسل اول بود: Servlet، JSP، EJB 1.x/2.x — و برای یک bean ساده دو interface (Home و Remote)، یک کلاس پیاده‌سازی و چند صفحه XML لازم بود. Spring دقیقاً به‌عنوان واکنش به همین پیچیدگی متولد شد. Java EE 5 (۲۰۰۶) نقطه‌ی عطف بود: annotation‌ها آمدند، EJB 3.0 تقریباً همه‌ی XML را حذف کرد و JPA 1.0 استاندارد شد. Java EE 6 ‏CDI و JAX-RS و مفهوم Web Profile را آورد و نسخه‌های ۷ و ۸ ‏WebSocket، JSON-P، JSON-B و Security 1.0 را اضافه کردند — ولی سرعت کند شده بود.

۲۰۱۷: انتقال به Eclipse Foundation. ‏Oracle کدها را داد اما علامت تجاری «Java» را نگه داشت؛ پس نه نام «Java EE» قابل استفاده بود، نه بسته‌های javax.* قابل تغییر و توسعه. Jakarta EE 8 (۲۰۱۹) همان API‌های قبلی با همان javax.* بود، فقط زیر حاکمیت جدید. Jakarta EE 9 (۲۰۲۰) همان big bang بود: تمام javax.* به jakarta.* رفت بدون هیچ feature جدید؛ هم‌زمان spec‌های مرده هم پاک شدند (XML RPC، XML Registries، Deployment، Management، entity bean‌های EJB 2.x). Jakarta EE 11 (۲۶ ژوئن ۲۰۲۵) ‏Jakarta Data 1.0، پشتیبانی virtual thread در Concurrency 3.1، پشتیبانی record در Persistence 3.2 و حذف ارجاع‌ها به SecurityManager را آورد.

هر spec نسخه‌ی خودش را دارد و با شماره‌ی پلتفرم یکی نیست. Jakarta EE 11 یعنی: Servlet 6.1، CDI 4.1، Persistence 3.2، RESTful Web Services 4.0، Data 1.0، Faces 4.1، Expression Language 6.0، WebSocket 2.2، Pages 4.0، Security 4.0، Validation 3.1، Concurrency 3.1. موقع جست‌وجوی مستندات همیشه نسخه‌ی spec را بزن، نه نسخه‌ی پلتفرم.

۳. ایده‌ی مرکزی: spec با چند پیاده‌سازی

وقتی در Spring می‌نویسی @Autowired، آن annotation یک پیاده‌سازی دارد: خود Spring. سند spec وجود ندارد؛ کد، خودِ spec است. وقتی در Jakarta EE می‌نویسی @Inject، پشتش سندی رسمی ایستاده و همان را Weld (در WildFly)، OpenWebBeans (در TomEE) یا موتور داخلی Quarkus پیاده می‌کنند — بدون اینکه کد تو تغییر کند.

نتیجه‌ی اول: dependency تو فقط API است.

<dependency>
  <groupId>jakarta.platform</groupId>
  <artifactId>jakarta.jakartaee-api</artifactId>
  <version>11.0.0</version>
  <scope>provided</scope>
</dependency>

آن provided قلب ماجراست: «موقع کامپایل لازمش دارم، در بسته‌ی نهایی نگذارش — محیط اجرا خودش دارد»؛ پس WAR نهایی می‌تواند چند صد کیلوبایت باشد. (برای Web Profile همان مختصات با artifact ‏jakarta.jakartaee-web-api.) در Spring Boot عکس این است: از Tomcat تا Jackson، همه‌چیز داخل fat jar می‌آید.

نتیجه‌ی دوم: محصول یا «Jakarta EE 11 certified» هست یا نیست، و این را TCK تعیین می‌کند. نتیجه‌ی سوم: چند فروشنده‌ی رقیب برای یک API — برای JPA ‏Hibernate و EclipseLink؛ برای JAX-RS ‏Jersey و RESTEasy و CXF؛ برای CDI ‏Weld و OpenWebBeans؛ برای JTA ‏Narayana و Atomikos.

۴. زلزله‌ی javax → jakarta

توافق نهایی این بود که Eclipse Foundation می‌تواند بسته‌های javax.* موجود را نگه دارد ولی حق تغییر یا افزودن به آن‌ها را ندارد — یعنی javax.servlet برای همیشه در Servlet 4.0 یخ می‌زد؛ تنها راه ادامه‌ی تکامل، تغییر نام کل namespace بود.

چرا این همه‌چیز را شکست؟ چون در JVM نام بسته بخشی از هویت باینری کلاس است. javax.servlet.http.HttpServlet و jakarta.servlet.http.HttpServlet دو کلاس کاملاً بی‌ربط‌اند: نه interface مشترکی، نه رابطه‌ی وراثتی، نه تبدیل خودکاری. پس هر کتابخانه‌ای که به javax.* اشاره می‌کرد باید دوباره کامپایل و منتشر می‌شد — Hibernate، Jackson، Jersey، Tomcat، Jetty و ابزارهای build. این چند سال طول کشید.

mvn dependency:tree | grep -iE 'javax\.(servlet|persistence|validation|inject|annotation)'

دو ابزار برای عبور از این شکاف داری. اگر همه‌ی کتابخانه‌هایت نسخه‌ی jakarta دارند، مسیر ساده است؛ اگر نه، باید یا کتابخانه را از سورس دوباره build کنی یا بایت‌کدش را بازنویسی کنی.

ابزار ۱ — OpenRewrite، وقتی سورس را داری. یک بار اجرا می‌کنی و import‌ها، وابستگی‌های Maven/Gradle و بسیاری از API‌های حذف‌شده جابه‌جا می‌شوند (برای هدف قبلی، …jakarta.JakartaEE10):

mvn -U org.openrewrite.maven:rewrite-maven-plugin:run \
  -Drewrite.recipeArtifactCoordinates=org.openrewrite.recipe:rewrite-migrate-java:RELEASE \
  -Drewrite.activeRecipes=org.openrewrite.java.migrate.jakarta.JakartaEE11

ابزار ۲ — Eclipse Transformer، وقتی سورس یک کتابخانه را نداری. روی بایت‌کد کار می‌کند: یک JAR/WAR/EAR می‌گیرد و یکی جدید با نام‌های عوض‌شده می‌دهد. در Maven به‌صورت org.eclipse.transformer:transformer-maven-plugin (نسخه‌ی 0.5.0) با <extensions>true</extensions> و قاعده‌ی <jakartaDefaults>true</jakartaDefaults> اضافه می‌شود و goal های jar و transform را دارد.

۵. محیط اجرا: سرور، کانتینر، fat jar

سه چیز را مردم قاطی می‌کنند. application server مثل هتل کامل است: چمدانت (WAR/EAR) را می‌بری و همه‌ی سرویس‌ها آماده‌اند. servlet container مثل آپارتمان خالی است: دیوار و برق و آب داری (HTTP و چرخه‌ی حیات Servlet) ولی یخچال و لباس‌شویی را خودت باید بیاوری (JPA، تراکنش، DI). fat jar مثل کاروان است: خانه را با خودت حمل می‌کنی — هیچ زیرساخت بیرونی لازم نیست، ولی مسئول هر چیزی هستی که داخلش گذاشته‌ای، از جمله وصله‌های امنیتی.

آن سطر آخر مهم‌تر از چیزی است که به نظر می‌رسد: وقتی یک CVE در Tomcat منتشر می‌شود و صد میکروسرویس Spring Boot داری، باید صد برنامه را دوباره build و deploy کنی؛ در مدل application server تیم عملیات یک بار runtime را patch می‌کند. جواب مدرن، خودکارسازی build و base image مشترک است (containers-jvm) — و آوردن هر دو طرف این بحث در مصاحبه نشان می‌دهد شعار تکرار نمی‌کنی.

۶. Servlet: پایه‌ای که همه‌چیز روی آن ساخته شده

Servlet یعنی کلاسی که یک درخواست HTTP می‌گیرد و یک پاسخ می‌دهد. هر چیزی که در وب Java می‌بینی — JSF، JAX-RS، Spring MVC، حتی Spring Boot در حالت پیش‌فرض — در نهایت روی Servlet سوار است.

servlet container مثل اداره‌ای است که در را باز می‌کند، صف را مدیریت می‌کند و مشتری را جلوی باجه می‌گذارد؛ Servlet تو فقط کارمند پشت باجه است. نکته‌ی حیاتی: اداره برای هر مشتری کارمند جدید استخدام نمی‌کند — یک instance ساخته می‌شود و ده‌ها thread هم‌زمان واردش می‌شوند.

نمودار: چرخه‌ی حیات یک Servlet از دید کانتینر.

stateDiagram-v2
    [*] --> Loaded: class loaded by container
    Loaded --> Initialized: init(ServletConfig) once
    Initialized --> Servicing: service() per request
    Servicing --> Servicing: many threads concurrently
    Servicing --> Destroyed: destroy() on shutdown or undeploy
    Destroyed --> [*]

یک نمونه‌ی کمینه: کلاسی با @WebServlet(urlPatterns = {"/health"}, loadOnStartup = 1) که از HttpServlet ارث می‌برد، یک شمارنده‌ی AtomicLong دارد (state مشترک باید thread-safe باشد) و doGet را override می‌کند تا JSON را در resp.getWriter() بنویسد.

Filter زنجیره‌ی میان‌افزار است: کلاسی با @WebFilter(urlPatterns = "/api/*") که Filter را پیاده می‌کند، قبل و بعد از Servlet اجرا می‌شود و باید chain.doFilter(req, res) را صدا بزند وگرنه درخواست همان‌جا می‌میرد؛ معادل مفهومی فیلترهای امنیتی و HandlerInterceptor در Spring. کاربرد کلاسیکش گذاشتن یک شناسه‌ی همبستگی در MDC است: از Servlet 6.0 متد getRequestId() روی درخواست، شناسه‌ای یکتا در طول عمر کانتینر می‌دهد (کنارش getProtocolRequestId() و getServletConnection() هم آمدند) — الگوی درست در logging و observability. Listener — کلاسی با @WebListener که ServletContextListener یا HttpSessionListener را پیاده می‌کند — به رویدادهای چرخه‌ی حیات گوش می‌دهد: بالا آمدن context، ساخت session، تغییر attribute.

قبل از Servlet 3.0 همه‌چیز باید در WEB-INF/web.xml اعلام می‌شد. امروز annotation کافی است، ولی web.xml هنوز برای تنظیمات محیطی، override، امنیت اعلانی و ترتیب فیلترها (که با annotation قابل کنترل نیست) لازم می‌شود:

یک نمونه‌ی کمینه <session-timeout>30</session-timeout> را می‌گذارد، کوکی نشست را با <http-only>true</http-only> و <secure>true</secure> علامت می‌زند و <tracking-mode>COOKIE</tracking-mode> را قفل می‌کند.

امنیت اعلانی در سطح URL هم در همین فایل است: یک <security-constraint> که یک <web-resource-collection> (مثلاً /admin/*) را به یک <auth-constraint> با نام نقش لازم گره می‌زند.

myapp.war
├── index.html , css/ , js/    ← عمومی، مستقیم قابل دسترسی
└── WEB-INF/
    ├── web.xml , beans.xml    ← پیکربندی وب و فعال‌سازی CDI
    ├── classes/ , lib/        ← کلاس‌های خودت و JAR های وابسته
    └── views/                 ← غیرقابل دسترسی از بیرون

JSP و JSF هم همین‌جا جا می‌گیرند. JSP یعنی HTML با کد Java تعبیه‌شده که کانتینر آن را به یک Servlet ترجمه می‌کند؛ JSF یک فریم‌ورک کامپوننت‌محور و stateful برای UI سمت سرور است که درخت کامپوننت را روی سرور نگه می‌دارد. کنار رفتند چون UI به React/Angular/Vue رفت و چون state سمت سرور برای مقیاس افقی نیاز به replication یا sticky session دارد. با این حال JSF زنده است (Faces 4.1 در EE 11) و برای پنل ادمین هنوز بهره‌ور است — در مصاحبه نگو «JSF مرده»، بگو «برای این کلاس مسائل کنار گذاشته شد و برای آن کلاس هنوز منطقی است».

۷. CDI: قلب Jakarta EE مدرن

CDI یعنی Contexts and Dependency Injection: تزریق وابستگی به‌علاوه‌ی context (کانتینر می‌داند هر شیء چقدر عمر می‌کند و کِی نابود شود). اگر DI ساده انباری است که هر ابزاری بخواهی می‌دهد، CDI انباری است با قانون امانت: این دریل تا آخر شیفت مال توست، این نردبان تا آخر پروژه، و آن جرثقیل یکی است و تا ابد در انبار می‌ماند — و انبار موقع پس گرفتن تمیزکاری هم می‌کند.

«bean» یعنی کلاسی که کانتینر بتواند نمونه‌اش را بسازد و مدیریت کند: یک constructor بدون آرگومان (یا یکی با @Inject) و قرار داشتن در یک bean archive — یعنی JAR یا WEB-INF/classes که CDI در آن دنبال bean می‌گردد و با beans.xml کنترل می‌شود.

دو پیاده‌سازی از یک interface داری؛ کانتینر از کجا بداند کدام را تزریق کند؟ در Spring @Qualifier("name") یا @Primary؛ در CDI، qualifier یک annotation تایپ‌دار است:

@Qualifier
@Retention(RetentionPolicy.RUNTIME)
@Target({ElementType.TYPE, ElementType.FIELD, ElementType.PARAMETER})
public @interface Gateway {
    Provider value();
    enum Provider { CARD, WALLET }
}

@ApplicationScoped @Gateway(Gateway.Provider.CARD)
class CardGateway implements PaymentGateway { /* ... */ }

@ApplicationScoped
public class CheckoutService {
    private final PaymentGateway gateway;

    @Inject
    CheckoutService(@Gateway(Gateway.Provider.CARD) PaymentGateway gateway) {
        this.gateway = gateway;      // بدون ابهام، بدون رشته‌ی جادویی
    }
}

برای اشیائی که خودت نمی‌سازی — مثلاً یک HttpClient — producer method معادل @Bean در Spring است: متدی با @Produces و در صورت نیاز یک @Disposes برای آزادسازی. رویدادها هم یک event bus داخلی و همگام می‌دهند، معادل ApplicationEventPublisher:

@Inject Event<OrderPlaced> orderPlaced;          // انتشار
orderPlaced.fire(new OrderPlaced(orderId, amountMinor));

// دریافت — فقط بعد از commit موفق تراکنش اجرا می‌شود
void onOrder(@Observes(during = TransactionPhase.AFTER_SUCCESS) OrderPlaced event) { }

آن TransactionPhase.AFTER_SUCCESS یک ابزار سنیوری است: باگ «ایمیل فرستادم ولی تراکنش rollback شد» یکی از رایج‌ترین اشکالات منطقی سیستم‌های سازمانی است، و این تضمین می‌کند عارضه‌ی بیرونی فقط بعد از commit موفق رخ دهد (معادل Spring: ‏@TransactionalEventListener).

Interceptor نسخه‌ی استاندارد و اعلانی AOP است: به‌جای pointcut expression، یک annotation با @InterceptorBinding می‌سازی (مثلاً @Audited)، بعد کلاسی با @Audited @Interceptor @Priority(Interceptor.Priority.APPLICATION) که متدی با @AroundInvoke و پارامتر InvocationContext دارد و داخلش ctx.proceed() را صدا می‌زند. بدون @Priority (یا اعلان در beans.xml) اصلاً فعال نمی‌شود — اشتباه بسیار رایج.

۸. EJB: چرا بدنام شد و چه چیزی ماند

EJB (امروز Jakarta Enterprise Beans) ایده‌ی ساده‌ای داشت: تو منطق کسب‌وکار را بنویس، کانتینر تراکنش، امنیت، pooling و concurrency را انجام دهد. بدنامی از EJB 2.x می‌آید: برای یک bean ساده یک interface Home، یک Remote، یک کلاس bean و یک ejb-jar.xml طولانی؛ Entity Bean‌ها کند و پیچیده بودند و جایشان را JPA گرفت؛ و تست کردن تقریباً غیرممکن بود. همین فضا Spring را ساخت. از EJB 3.0 (۲۰۰۶) همه‌ی آن پیچیدگی حذف شد ولی شهرت بد ماند؛ در Jakarta EE 9 هم API‌های EJB 2.x رسماً اختیاری شدند.

@Stateless
public class InvoiceService {

    @PersistenceContext(unitName = "billingPU")
    private EntityManager em;

    // پیش‌فرض REQUIRED: اگر تراکنشی هست بپیوند، وگرنه بساز
    @RolesAllowed("BILLING_CLERK")
    public void issue(Invoice invoice) {
        em.persist(invoice);
    }

    // همیشه تراکنش جدید — برای لاگ حسابرسی که نباید با شکست اصلی rollback شود
    @TransactionAttribute(TransactionAttributeType.REQUIRES_NEW)
    public void auditTrail(String message) {
        em.persist(new AuditEntry(message));
    }
}

نکته‌ی بزرگ: هیچ @Transactionalای در کد نیست و با این حال هر متد عمومی تراکنش‌دار است. این همان CMT (Container-Managed Transaction) است.

چهار نوع bean داریم: @Stateless (بدون state بین فراخوانی‌ها، از یک pool — سرویس‌های کسب‌وکار، ۹۰٪ موارد)، @Stateful (state مخصوص هر کلاینت — جادوگر چندمرحله‌ای، سبد خرید)، @Singleton (یک instance در کل برنامه — cache، زمان‌بند، بارگذاری اولیه) و @MessageDriven (مصرف‌کننده‌ی پیام، بدون کلاینت مستقیم).

۹. JPA، JTA و تراکنش‌های توزیع‌شده

عمق JPA در فصل jpa-hibernate است؛ اینجا فقط بخش مخصوص Jakarta EE: persistence unit مدیریت‌شده توسط کانتینر. در META-INF/persistence.xml یک <persistence-unit name="billingPU" transaction-type="JTA"> تعریف می‌کنی که به یک <jta-data-source> اشاره دارد.

با JTA کانتینر مالک تراکنش است؛ EntityManager را با @PersistenceContext می‌گیری و هرگز em.getTransaction() را صدا نمی‌زنی (اگر بزنی IllegalStateException می‌گیری). با RESOURCE_LOCAL خودت مالک هستی و begin()/commit() را صریح می‌نویسی — حالت Java SE. قاطی کردن این دو یکی از رایج‌ترین خطاهای runtime هنگام تست خارج از سرور است.

JTA (Jakarta Transactions) استانداردی است برای تراکنش‌هایی که چند منبع را در بر می‌گیرند: دو دیتابیس، یا یک دیتابیس و یک صف. مکانیزم زیرین two-phase commit است و به درایورهای XA نیاز دارد — مثل معامله‌ای با محضردار: اول از همه می‌پرسد «آماده‌ای؟» (فاز prepare) و فقط اگر همه بله بگویند دستور امضا می‌دهد (فاز commit).

نمودار: پروتکل two-phase commit در JTA.

sequenceDiagram
    participant App as Application
    participant TM as Transaction Manager
    participant DB as XA Database
    participant MQ as XA Message Broker
    App->>TM: begin()
    App->>DB: insert row
    App->>MQ: send message
    App->>TM: commit()
    TM->>DB: prepare
    TM->>MQ: prepare
    DB-->>TM: vote yes
    MQ-->>TM: vote yes
    TM->>DB: commit
    TM->>MQ: commit
    TM-->>App: committed

در Jakarta EE مدرن حتی بدون EJB هم تراکنش اعلانی داری: کافی است @Transactional(Transactional.TxType.REQUIRED) را روی متد یک CDI bean بگذاری. توجه: این jakarta.transaction.Transactional است نه نسخه‌ی Spring؛ رفتار مشابه است ولی با rollbackOn و dontRollbackOn تنظیم می‌شود. برای کنترل دستی، @Resource UserTransaction utx; را تزریق می‌کنی.

خواندن رویدادهای منتشرنشده‌ی outbox توسط چند worker هم‌زمان:

SELECT id, aggregate_id, event_type, payload
FROM outbox
WHERE published_at IS NULL
ORDER BY created_at
LIMIT 100
FOR UPDATE SKIP LOCKED;

SELECT id, aggregate_id, event_type, payload
FROM outbox
WHERE published_at IS NULL
ORDER BY created_at
FETCH FIRST 100 ROWS ONLY
FOR UPDATE SKIP LOCKED;

۱۰. JMS و Bean Validation

JMS (امروز Jakarta Messaging) یک API استاندارد برای صف و topic است — نه یک پروتکل سیمی مثل AMQP؛ یعنی با یک کلاینت JMS به هر broker دلخواهی وصل نمی‌شوی. دو مدل دارد: Queue (هر پیام به یک مصرف‌کننده) و Topic (هر پیام به همه‌ی مشترکان). مصرف‌کننده در Jakarta EE کلاسیک یک MDB است:

@MessageDriven(activationConfig = {
    @ActivationConfigProperty(propertyName = "destinationType",
                              propertyValue = "jakarta.jms.Queue"),
    @ActivationConfigProperty(propertyName = "destinationLookup",
                              propertyValue = "java:/jms/queue/Orders")
})
public class OrderConsumer implements MessageListener {
    @Override
    public void onMessage(Message m) {
        try { if (m instanceof TextMessage t) { process(t.getText()); } }
        catch (JMSException e) { throw new IllegalStateException("bad message", e); }
    }
}

سمت تولید، JMSContext را با @Inject می‌گیری، مقصد را با @Resource(lookup = "…") و بعد context.createProducer().send(queue, payload) — داخل یک متد @Transactional.

Jakarta Validation (که همه هنوز Bean Validation صدایش می‌زنند) استاندارد اعتبارسنجی با annotation است — و Spring هم دقیقاً از همین spec استفاده می‌کند (پیاده‌سازی رایج: Hibernate Validator)، پس این دانش صددرصد بین دو دنیا منتقل می‌شود.

public record CreateOrderRequest(
        @NotBlank @Size(max = 64) String accountId,
        @Positive long amountMinor,
        @Email String notifyEmail) {}

نکته‌ی مخصوص Jakarta EE: اعتبارسنجی خودکار در چند نقطه اعمال می‌شود — روی پارامترهای متدهای EJB و CDI با @Valid، روی بدنه‌ی درخواست در JAX-RS، و روی entity های JPA قبل از persist/update. همین مورد آخر غافلگیرکننده است: خطا در لحظه‌ی flush پرتاب می‌شود که می‌تواند خیلی دورتر از جایی باشد که فکر می‌کنی؛ با jakarta.persistence.validation.mode می‌توانی آن را روی NONE یا CALLBACK تنظیم کنی.

۱۱. JAX-RS در برابر Spring MVC

JAX-RS (امروز Jakarta RESTful Web Services، نسخه‌ی 4.0 در EE 11) استاندارد ساخت REST API است.

@Path("/orders")
@ApplicationScoped
@Produces(MediaType.APPLICATION_JSON)
@Consumes(MediaType.APPLICATION_JSON)
public class OrderResource {

    @Inject OrderService service;
    @Context UriInfo uriInfo;

    @GET @Path("/{id}")
    public Response findById(@PathParam("id") String id) {
        return service.find(id).map(Response::ok)
                .orElseGet(() -> Response.status(Response.Status.NOT_FOUND)).build();
    }

    @POST
    public Response create(@Valid CreateOrderRequest request) {
        String id = service.create(request);
        return Response.created(uriInfo.getAbsolutePathBuilder().path(id).build()).build();
    }
}

@ApplicationPath("/api")
public class RestActivator extends Application {}

مدیریت خطا با یک کلاس @Provider که ExceptionMapper<MyException> را پیاده می‌کند — معادل @ControllerAdvice با @ExceptionHandler در Spring.

از نظر طراحی JAX-RS تمیزتر است و کلاینت استاندارد در همان spec دارد؛ Spring MVC از نظر بهره‌وری جلوتر است چون بدون کلاس فعال‌سازی کار می‌کند و با validation و امنیت و مستندسازی از پیش سیم‌کشی شده. نکته‌ی سنیوری: هر دو روی Servlet می‌نشینند و هیچ‌کدام یک API خوب طراحی نمی‌کنند — کیفیت API از نام‌گذاری منابع، کدهای وضعیت، صفحه‌بندی، نسخه‌بندی و idempotency می‌آید (api-design).

۱۲. JAX-WS، JNDI و Jakarta Security

SOAP پروتکل پیام مبتنی بر XML است و WSDL قراردادی ماشین‌خوان که می‌گوید سرویس چه عملیاتی دارد. JAX-WS (Jakarta XML Web Services) ‏API استاندارد Java برای این دنیاست: یک کلاس با @WebService و متدهایی با @WebMethod کافی است تا کانتینر WSDL را تولید کند؛ ابزار wsimport هم از یک WSDL کلاس‌های کلاینت می‌سازد (در JDK‌های مدرن از خود JDK حذف شده و از توزیع مستقل Jakarta XML Web Services Tools می‌آید).

در Jakarta EE 9 خانواده‌ی سرویس‌های وب XML از هسته‌ی پلتفرم بیرون رفت و اختیاری شد — ولی در بانک، بیمه و تبادل داده‌ی بین‌سازمانی هنوز رایج است، چون WSDL قراردادی رسمی و قابل تولید کد می‌دهد و WS-Security امضا و رمزنگاری در سطح پیام دارد، نه فقط سطح انتقال مثل TLS. معادل مدرن این قرارداد رسمی، OpenAPI و gRPC هستند (api-design، grpc-protobuf).

JNDI یعنی Java Naming and Directory Interface: دفترچه‌تلفن داخل سرور. برنامه با @Resource(lookup = "java:app/jdbc/BillingDS") یک DataSource می‌گیرد بدون اینکه بداند پشت آن نام چیست — مثل تلفنچی شرکت: نام منطقی ثابت می‌ماند، منبع فیزیکی عوض می‌شود. خود datasource در سرور تعریف می‌شود (WildFly با jboss-cli.sh، Payara با asadmin create-jdbc-connection-pool) یا با annotation استاندارد @DataSourceDefinition. فضاهای نام به ترتیب دامنه‌ی دید: java:comp/env/…، java:module/…، java:app/… (قابل حمل‌ترین انتخاب) و java:global/…؛ هر چیزی مثل java:jboss/… اختصاصی فروشنده است.

چرا pool را داخل برنامه نگذاریم؟ وقتی ۴۰ سرویس Spring Boot هر کدام یک HikariCP بیست‌تایی دارند، دیتابیس با ۸۰۰ اتصال روبه‌رو می‌شود در حالی که max_connections معمولاً خیلی کمتر است — قطعی سراسری در ساعت اوج. در مدل container-managed این بودجه در یک جا دیده و پایش می‌شود؛ اگر Spring Boot را انتخاب می‌کنی، بودجه‌ی اتصال را در سطح پلتفرم مدیریت کن.

Jakarta Security (نسخه‌ی 4.0 در EE 11) امنیت را استاندارد کرد؛ قبلاً هر سرور مفهوم خودش را داشت. سه مفهوم پایه: Authentication Mechanism (@BasicAuthenticationMechanismDefinition، ‏@FormAuthenticationMechanismDefinition یا @OpenIdAuthenticationMechanismDefinition برای OIDC)، Identity Store (مثلاً @DatabaseIdentityStoreDefinition با callerQuery، groupsQuery و یک hashAlgorithm)، و SecurityContext که با @Inject می‌گیری و getCallerPrincipal() می‌دهد. برای مجوزدهی @RolesAllowed روی EJB و CDI bean کار می‌کند و در سطح URL هم <security-constraint>. در دنیای میکروسرویس معمولاً MicroProfile JWT استفاده می‌شود؛ عمق RBAC/ABAC در ms-security است.

۱۳. بسته‌بندی: WAR، EAR و fat jar

WAR یک ماژول وب است. EAR (Enterprise Archive) ظرفی است که چند ماژول را با هم بسته‌بندی می‌کند — چند WAR، چند EJB-JAR و کتابخانه‌های مشترک در lib/ — با یک META-INF/application.xml که ماژول‌ها و context-root ها را فهرست می‌کند.

۱۴. MicroProfile و نسل جدید runtime‌ها

Jakarta EE برای برنامه‌های بزرگ و یکپارچه طراحی شده بود. با موج میکروسرویس چیزهایی لازم شد که در spec نبود: پیکربندی بیرونی، health check، متریک، مستندسازی خودکار API، circuit breaker و JWT. MicroProfile همین شکاف را پر کرد: مجموعه‌ای از spec‌های سبک روی Jakarta EE Core Profile.

یک تغییر مهم که در مصاحبه امتیاز دارد: تا MicroProfile 6.1 ‏MicroProfile Metrics بخشی از چتر بود؛ از MicroProfile 7.0 جایش را MicroProfile Telemetry گرفت که بر پایه‌ی OpenTelemetry هر سه رکن مشاهده‌پذیری را می‌دهد و Metrics به یک spec مستقل بیرون از چتر تبدیل شد — همان مسیری که کل صنعت رفت (observability).

@ApplicationScoped
public class RateClient {

    @Inject @ConfigProperty(name = "pricing.currency", defaultValue = "EUR")
    String currency;

    @Retry(maxRetries = 3, delay = 200, jitter = 100)
    @Timeout(value = 2, unit = ChronoUnit.SECONDS)
    @CircuitBreaker(requestVolumeThreshold = 20, failureRatio = 0.5, delay = 10000)
    @Fallback(fallbackMethod = "cachedRate")
    public double currentRate(String pair) { /* فراخوانی سرویس بیرونی */ }

    double cachedRate(String pair) { return 1.0; }   // جایگزین، با همان امضا
}

ترتیب استاندارد اولویت پیکربندی از بالا به پایین: متغیرهای محیطی، سپس system property های JVM، سپس META-INF/microprofile-config.properties — همان چیزی که در Kubernetes با ConfigMap و Secret می‌خواهی. برای health، یک کلاس @Readiness @ApplicationScoped که HealthCheck را پیاده کند کافی است. و برای فراخوانی سرویس دیگر، یک interface با @RegisterRestClient(configKey = "catalog-api") بنویس و URL و timeout را در catalog-api/mp-rest/url و …/connectTimeout بگذار — معادل FeignClient.

مشکل application server کلاسیک این بود که برای دنیای کانتینر سنگین بود: حافظه‌ی بالا، بالا آمدن کند، و reflection زیاد در زمان اجرا. نسل جدید همان API‌ها را برمی‌دارد ولی معماری اجرا را عوض می‌کند: Quarkus کارهای سنگین (پویش CDI، متادیتای JPA، جدول مسیرها) را به زمان build منتقل می‌کند و کامپایل native با GraalVM می‌دهد. Helidon از نسخه‌ی ۴ روی virtual thread های Java 21 بازنویسی شده (virtual-threads). Open Liberty مدل feature-based دارد: فقط قابلیت‌هایی که در server.xml اعلام کنی (مثل restfulWS-4.0، cdi-4.1، mpConfig-3.1) بارگذاری می‌شوند.

quarkus create app com.example:billing --extension='rest-jackson,hibernate-orm-panache'
quarkus dev                                                   # توسعه با بارگذاری زنده
./mvnw package -Dnative -Dquarkus.native.container-build=true  # اجرایی native

۱۵. جدول بزرگ: Jakarta EE در برابر Spring

۱۶. مسیرهای مهاجرت

نمودار: درخت تصمیم برای مهاجرت یک سیستم Java EE قدیمی.

flowchart TD
    A[Legacy Java EE app] --> B{Is the business logic<br/>worth preserving as-is?}
    B -->|No, rewrite planned| C[Strangler Fig to<br/>Spring Boot or Quarkus]
    B -->|Yes| D{Heavy use of EJB,<br/>JMS, JTA, JSF?}
    D -->|Yes| E[Modernize in place:<br/>Jakarta EE 11 runtime]
    D -->|No, mostly CDI + JAX-RS| F[Lift to Quarkus:<br/>same annotations]
    E --> G[Then containerize]
    F --> G
    C --> G

مسیر ۱ — مدرن‌سازی در جا: سرور را به یک runtime مدرن ببر (Open Liberty، WildFly، Payara)، namespace را عوض کن و کد را تقریباً دست‌نخورده نگه دار — کم‌ریسک‌ترین مسیر. مسیر ۲ — انتقال به Quarkus: اگر برنامه عمدتاً CDI + JAX-RS + JPA است، بیشترین کد حفظ می‌شود. مسیر ۳ — Strangler Fig به سمت Spring Boot: یک gateway جلوی سیستم قدیمی می‌گذاری و هر بار یک قابلیت را منتقل می‌کنی (hexagonal-clean).

۱۷. برگه‌ی تقلب دستورها