Java đã thay đổi đáng kể cách phát hành trong gần một thập kỷ qua. Từ mô hình phát hành các phiên bản lớn cách nhau nhiều năm, Java chuyển sang một chu kỳ phát hành đều đặn hơn, với một feature release mới mỗi sáu tháng. OpenJDK hiện duy trì cadence này theo mô hình time-based release, với các phiên bản mới được phát hành vào khoảng tháng 3 và tháng 9. JDK 10, phát hành tháng 3/2018, là phiên bản đầu tiên được xây dựng theo mô hình sáu tháng này.
Sự thay đổi này mang lại tốc độ phát triển tính năng nhanh hơn, nhưng đồng thời đặt ra một bài toán quan trọng đối với doanh nghiệp: nên lựa chọn phiên bản Java nào, nâng cấp theo chu kỳ nào và làm thế nào để migration mà không ảnh hưởng đến hệ thống production?
Đặc biệt, sự xuất hiện của các bản LTS như Java 17, Java 21 và Java 25 khiến chiến lược lựa chọn JDK trở thành một phần quan trọng trong việc quản trị vòng đời nền tảng Enterprise.
Bài viết này sẽ phân tích chu kỳ phát hành của Java, giải thích bản chất của LTS, những rủi ro khi duy trì Java 8/11 quá lâu và xây dựng một lộ trình migration thực tế cho các hệ thống doanh nghiệp.
Chu kỳ phát hành 6 tháng/lần của Java
1. Hiểu đúng về chu kỳ phát hành của Java
Trước Java 9, Java thường được phát triển theo những chu kỳ tương đối dài. Mỗi phiên bản lớn có thể cách nhau nhiều năm, khiến doanh nghiệp có xu hướng triển khai một phiên bản rồi duy trì trong thời gian rất dài.
Mô hình này thay đổi từ năm 2017 với time-based release model. Theo mô hình hiện tại, OpenJDK phát hành một feature release mới mỗi sáu tháng. JDK 10 là feature release đầu tiên theo cadence này vào tháng 3/2018, tiếp theo là JDK 11 vào tháng 9/2018.
Điều này tạo ra hai nhóm phiên bản mà các tổ chức cần phân biệt:
- Feature Release: phát hành sáu tháng một lần, tập trung đưa các tính năng và cải tiến mới vào nền tảng.
- LTS Release: những phiên bản được các vendor lựa chọn để cung cấp lifecycle hỗ trợ dài hơn, phù hợp với các hệ thống cần thời gian vận hành và bảo trì lâu dài.
Điểm quan trọng là LTS không có nghĩa phiên bản đó “ổn định hơn” theo nghĩa các phiên bản non-LTS không thể chạy production. Non-LTS vẫn là các bản phát hành chính thức của Java và được kiểm thử theo quy trình phát hành của OpenJDK. Sự khác biệt chủ yếu nằm ở chiến lược lifecycle và support của từng vendor.
2. LTS thực sự có nghĩa gì?
LTS, viết tắt của Long-Term Support, thường được hiểu đơn giản là “phiên bản được hỗ trợ lâu dài”. Tuy nhiên, cần phân biệt giữa release designation và support policy.
LTS không tự quy định rằng mọi vendor phải hỗ trợ một phiên bản trong cùng một khoảng thời gian. Thời gian và điều kiện hỗ trợ phụ thuộc vào vendor, distribution và chính sách support cụ thể.
Theo roadmap hiện tại của Oracle, Java 8, 11, 17, 21 và 25 đều là các LTS release. Oracle hiện định hướng chu kỳ LTS hai năm một lần, với Java 29 được lên kế hoạch là LTS tiếp theo vào tháng 9/2027.
Do đó, không nên hiểu rằng “startup dùng non-LTS, Enterprise dùng LTS”. Một startup hoàn toàn có thể lựa chọn LTS để giảm chi phí vận hành, trong khi một tổ chức lớn có platform engineering trưởng thành vẫn có thể sử dụng các feature release nếu có khả năng nâng cấp thường xuyên.
LTS và Non-LTS: Hai chiến lược sử dụng Java
3. Nhìn lại các mốc LTS quan trọng: Java 17, 21 và 25
3.1 Java 17 LTS – Nền tảng cho quá trình hiện đại hóa
Java 17, phát hành tháng 9/2021, là một cột mốc quan trọng trong quá trình hiện đại hóa Java Enterprise.
Một số thay đổi đáng chú ý gồm:
- Records được chuẩn hóa từ Java 16.
- Sealed Classes trở thành tính năng chính thức.
- Nhiều cải tiến đối với JVM và Garbage Collector.
- Strong encapsulation tiếp tục được tăng cường.
- G1GC tiếp tục là Garbage Collector mặc định, trong khi ZGC là một lựa chọn dành cho các workload có yêu cầu latency thấp.
Java 17 cũng trở thành nền tảng quan trọng cho thế hệ framework Enterprise mới. Đặc biệt, Spring Framework 6 và Spring Boot 3 yêu cầu tối thiểu Java 17.
3.2 Java 21 LTS – Bước tiến về concurrency
Java 21, phát hành tháng 9/2023, mang đến một trong những thay đổi đáng chú ý nhất của Java trong nhiều năm: Virtual Threads.
Virtual Threads cho phép ứng dụng tạo số lượng lớn concurrent tasks với chi phí thấp hơn so với việc sử dụng platform threads truyền thống. Điều này đặc biệt hữu ích đối với các workload có nhiều thao tác blocking I/O, chẳng hạn HTTP calls hoặc database operations.
Bên cạnh Virtual Threads, Java 21 còn chuẩn hóa nhiều tính năng ngôn ngữ và API đáng chú ý như:
- Pattern Matching for switch.
- Record Patterns.
- Sequenced Collections.
- Structured Concurrency và Scoped Values ở dạng preview.
Điểm cần lưu ý là Virtual Threads không tự động biến mọi ứng dụng thành hệ thống có thể xử lý hàng triệu request. Hiệu năng thực tế vẫn phụ thuộc vào database, connection pool, downstream services, memory, network và kiến trúc ứng dụng.
3.3 Java 25 LTS – LTS mới nhất
Java 25 đạt General Availability vào ngày 16/9/2025 và là LTS release mới nhất tính đến năm 2026.
JDK 25 tiếp tục tập trung vào cả ngôn ngữ, runtime và hiệu năng. Một số thay đổi đáng chú ý gồm:
- Scoped Values được chuẩn hóa.
- Compact Source Files and Instance Main Methods.
- Flexible Constructor Bodies.
- Ahead-of-Time Command-Line Ergonomics.
- Ahead-of-Time Method Profiling.
- Compact Object Headers.
- Generational Shenandoah.
- Nhiều cải tiến khác liên quan đến JVM, JFR và API.
Danh sách chính thức của OpenJDK cho thấy JDK 25 bao gồm nhiều JEP mới, trong đó một số tính năng vẫn ở trạng thái Preview hoặc Experimental. Vì vậy, không nên xem toàn bộ tính năng của Java 25 là API production-ready giống nhau.
4. Rủi ro khi duy trì JDK 8 hoặc JDK 11 quá lâu
Việc một hệ thống vẫn chạy Java 8 hoặc Java 11 không đồng nghĩa hệ thống đó ngay lập tức không an toàn. Trên thực tế, các phiên bản này vẫn có lifecycle hỗ trợ từ nhiều vendor.
Ví dụ, roadmap Oracle hiện tại cho thấy Java 8 có Extended Support đến tháng 12/2030, Java 11 đến tháng 1/2032, Java 17 đến tháng 9/2029 và Java 21 đến tháng 9/2031 theo chính sách Oracle dành cho khách hàng.
Vấn đề lớn hơn đối với doanh nghiệp nằm ở chi phí duy trì legacy stack và khoảng cách với hệ sinh thái hiện đại.
4.1 Dependency và Framework Compatibility
Đây thường là lý do thực tế nhất để doanh nghiệp bắt đầu migration.
Các framework hiện đại đã nâng yêu cầu JDK. Chẳng hạn:
- Spring Framework 6 yêu cầu Java 17+.
- Spring Boot 3 yêu cầu Java 17+.
- Hibernate 6 nằm trong hệ sinh thái Jakarta EE hiện đại và thường đi cùng yêu cầu Java/framework mới hơn.
Điều này có nghĩa một ứng dụng Java 8 có thể tiếp tục chạy ổn định, nhưng ngày càng khó tiếp cận những phiên bản framework và thư viện mới.
Đây chính là dạng technical debt do platform version.
4.2 JVM và hiệu quả vận hành
Các phiên bản JDK hiện đại liên tục cải thiện:
- Garbage Collection.
- JIT compiler.
- startup và runtime behavior.
- container awareness.
- observability.
- concurrency.
- memory management.
Tuy nhiên, không nên kết luận rằng nâng Java từ 8 lên 21 hoặc 25 sẽ tự động làm ứng dụng nhanh hơn trong mọi trường hợp.
Hiệu quả thực tế phải được đo bằng workload thực tế của từng hệ thống.
4.3 Chi phí migration tăng theo thời gian
Khoảng cách giữa JDK hiện tại và JDK mục tiêu càng lớn, số lượng compatibility issue cần xử lý thường càng nhiều.
Đặc biệt, migration có thể liên quan đồng thời đến:
- JDK API.
- JVM flags.
- Reflection và strong encapsulation.
- Build tool.
- Annotation processors.
- Framework.
- ORM.
- Serialization.
- Testing framework.
- Container image.
- CI/CD.
Một điểm quan trọng cần phân biệt là Java migration không đồng nghĩa với Jakarta migration. Việc chuyển javax.* sang jakarta.* thường phát sinh khi nâng các framework như Spring Boot 2 → 3, chứ không phải đơn thuần vì đổi JDK từ Java 8 sang Java 21.
5. Lộ trình Migration thực tế
Migration Java trong các hệ thống Enterprise không đơn thuần là thay đổi JAVA_HOME. Khi nâng cấp JDK, ứng dụng có thể đồng thời chịu tác động từ JVM, API, module system, thư viện bên thứ ba, framework và cấu hình runtime.
Một quy trình migration an toàn có thể thực hiện theo năm bước sau:
5.1 Bước 1. Phân tích và kiểm tra tính tương thích
Trước khi thay đổi JDK, cần đánh giá toàn bộ hệ sinh thái kỹ thuật của ứng dụng.
Công cụ JDeps, được cung cấp cùng JDK, có thể được sử dụng để phân tích dependency và phát hiện việc ứng dụng hoặc thư viện đang phụ thuộc vào các JDK Internal API có nguy cơ không còn được hỗ trợ.
Bên cạnh source code, cần kiểm tra compatibility của:
- Maven/Gradle và build plugins.
- Spring Framework / Spring Boot.
- Hibernate.
- Mockito.
- Lombok.
- Annotation processors.
- Các thư viện reflection và bytecode manipulation.
Đặc biệt, cần rà soát các JVM flags đang được sử dụng trong Docker, Kubernetes, CI/CD và production.
5.2 Bước 2. Cập nhật Build Tool và Dependencies
Migration nên được thực hiện trước tiên trên môi trường Development/Local. Trong Maven hoặc Gradle, cần cấu hình compiler hoặc Java toolchain để xác định rõ phiên bản JDK mục tiêu.
Các dependency quan trọng cũng cần được kiểm tra và cập nhật theo compatibility matrix của framework. Không nên áp dụng nguyên tắc “nâng tất cả dependency lên phiên bản mới nhất”. Cách tiếp cận an toàn hơn là xác định version range phù hợp, kiểm tra breaking changes và nâng cấp theo từng nhóm dependency có liên quan.
5.3 Bước 3. Xử lý Compatibility và Strong Encapsulation
Từ Java 9, Java Platform Module System (JPMS) đưa ra cơ chế encapsulation chặt chẽ hơn đối với các thành phần nội bộ của JDK. Một thư viện cũ sử dụng reflection để truy cập vào các thành phần không được mở của JDK có thể gặp lỗi:
java.lang.reflect.InaccessibleObjectException
Trong trường hợp chưa thể nâng cấp ngay dependency, các JVM options như:
–add-opens
–add-exports
có thể được sử dụng như giải pháp chuyển tiếp.
Tuy nhiên, đây không nên là giải pháp lâu dài. Dependency nên được nâng cấp lên phiên bản hỗ trợ JDK mới để loại bỏ sự phụ thuộc vào các cơ chế truy cập nội bộ.
5.4 Bước 4. Đánh giá và tối ưu hóa JVM
Migration cũng là thời điểm thích hợp để rà soát JVM configuration. Các flags được xây dựng cho Java 8 có thể đã obsolete hoặc không còn phù hợp với JDK hiện đại. Những cấu hình liên quan đến PermGen hoặc CMS cần được kiểm tra và loại bỏ nếu không còn được hỗ trợ.
Đối với Garbage Collector:
- G1GC là lựa chọn mặc định phù hợp cho nhiều workload Enterprise.
- ZGC có thể được cân nhắc khi hệ thống đặt yêu cầu cao về latency và pause time.
- Việc lựa chọn GC nên dựa trên workload, allocation rate, heap size, throughput và latency objective.
Không nên lựa chọn GC chỉ dựa trên một ngưỡng heap cố định.
5.5 Bước 5. Testing và Canary Deployment
Sau khi ứng dụng có thể build và khởi động trên JDK mới, cần chạy toàn bộ:
- Unit Test.
- Integration Test.
- End-to-End Test.
- Performance Test nếu hệ thống có yêu cầu cao về hiệu năng.
Ngoài functional correctness, cần so sánh:
- CPU utilization.
- Memory footprint.
- GC behavior.
- Response time.
- Throughput.
- Error rate.
- Startup time.
Đối với hệ thống có yêu cầu cao về availability, Canary Deployment là một chiến lược phù hợp. Một tỷ lệ traffic nhỏ có thể được chuyển sang các instance sử dụng JDK mới. Nếu metrics và behavior ổn định, quá trình rollout có thể được mở rộng dần.
Quan trọng nhất là phải có rollback strategy rõ ràng trước khi bắt đầu migration production.
Lộ trình Migration Java trong hệ thống Enterprise
6. Java 21 hay Java 25: Nên chọn phiên bản nào?
Không có một câu trả lời duy nhất cho mọi doanh nghiệp.
Tính đến năm 2026, Java 25 là LTS mới nhất, trong khi Java 21 là LTS trước đó. Oracle hiện công bố Java 21 với Premier Support đến tháng 9/2028 và Java 25 đến tháng 9/2030; các mốc cụ thể có thể khác nhau tùy vendor và chính sách support.
Do đó, việc lựa chọn nên dựa trên một số yếu tố chính.
6.1 Đang ở Java 8
Java 21 và Java 25 đều có thể là đích migration hợp lý. Nếu hệ thống đang sử dụng framework cũ, trước tiên cần xác định compatibility của framework và dependency. Trong một số trường hợp, việc nâng JDK và nâng framework nên được tách thành các phase riêng để giảm phạm vi thay đổi.
6.2 Đang ở Java 11
Java 21 hoặc Java 25 đều là những lựa chọn hợp lý. Nếu tổ chức muốn giảm số lần migration trong vài năm tới, Java 25 có thể là một lựa chọn đáng cân nhắc vì đây là LTS mới nhất. Nếu hệ sinh thái hiện tại đã được chuẩn hóa tốt trên Java 21, việc tiếp tục sử dụng Java 21 cũng hoàn toàn hợp lý.
6.3 Đang ở Java 17
Đây vẫn là một nền tảng tương đối hiện đại. Migration lên Java 21 hoặc 25 nên được quyết định dựa trên benefit thực tế thay vì chỉ vì “có phiên bản mới hơn”. Nếu ứng dụng cần Virtual Threads hoặc các cải tiến mới hơn của JVM, Java 21 là một bước nâng cấp đáng chú ý. Nếu tổ chức muốn chuyển sang LTS mới nhất và framework đã tương thích, Java 25 là một lựa chọn tự nhiên.
7. Migration không đồng nghĩa với Modernization
Một sai lầm phổ biến trong các dự án Enterprise là cố gắng thực hiện quá nhiều thay đổi trong cùng một lần release.
Java migration tập trung vào việc đưa ứng dụng hiện tại sang một JDK mới.
Framework migration có thể bao gồm Spring Boot 2 → 3, Hibernate version upgrade hoặc javax.* → jakarta.*.
Application modernization có phạm vi rộng hơn, chẳng hạn thay đổi architecture, database, deployment model hoặc cách tổ chức application.
Ba hoạt động này có thể liên quan với nhau nhưng không nên mặc định thực hiện cùng lúc.
Một chiến lược an toàn hơn là chia thành các phase:
JDK Migration
↓
Dependency Compatibility
↓
Framework Migration
↓
Application Modernization
Mỗi phase có thể có testing và rollback riêng. Điều này giúp giảm blast radius và quan trọng hơn, giúp đội ngũ xác định nguyên nhân khi xảy ra regression.
8Kết luận
Java hiện không còn là một nền tảng với những phiên bản lớn xuất hiện cách nhau nhiều năm. Mô hình release sáu tháng đã trở thành nền tảng phát triển của OpenJDK, trong khi các LTS release cung cấp những mốc phù hợp hơn cho các tổ chức cần lifecycle dài.
Với doanh nghiệp, câu hỏi quan trọng không phải là “phiên bản Java nào mới nhất?”, mà là:
“Phiên bản nào phù hợp nhất với lifecycle, framework, workload và năng lực vận hành của hệ thống?”
Java 8 hoặc Java 11 vẫn có thể tiếp tục vận hành nếu hệ thống có support phù hợp. Tuy nhiên, khoảng cách ngày càng lớn với framework và ecosystem hiện đại khiến việc trì hoãn migration có thể làm tăng technical debt và chi phí nâng cấp về sau.
Một chiến lược Java tốt vì vậy không phải là chạy theo mọi feature release, cũng không phải giữ một phiên bản LTS mãi mãi. Đó là việc xác định một JDK target phù hợp, duy trì upgrade cadence có kế hoạch và thực hiện migration theo từng bước có thể kiểm soát.
Với các hệ thống Enterprise, một quy trình thực tế có thể được khái quát:
Analyze → Update → Fix Compatibility → Validate → Tune → Canary → Rollout
Đây không chỉ là quy trình nâng cấp Java, mà là một phần của chiến lược quản trị vòng đời nền tảng phần mềm trong doanh nghiệp.
0 Lời bình