Java 25 / JDK 25 chính thức ra mắt

• Java 25 và bản triển khai tham chiếu JDK 25 đã chính thức được phát hành
• Phiên bản lần này bao gồm 18 JEP (Java Enhancement Proposal) mới
• Các thay đổi đáng chú ý gồm loại bỏ cổng x86 32-bit, Scoped Values, Structured Concurrency, cải tiến Primitive Types

---

Java 25 / JDK 25: phát hành chính thức

• JDK 25, tức bản triển khai tham chiếu của Java 25, đã chính thức được phát hành ở phiên bản sẵn sàng cho production
• Vào ngày 15 tháng 8 năm 2025, bản phát hành thử ứng viên thứ hai là build 36 đã được cung cấp, và kể từ đó không có báo cáo lỗi nghiêm trọng (P1) nào.
• build 36 là phiên bản GA (General Availability) cuối cùng, có thể sử dụng trong môi trường vận hành

• Bản dựng OpenJDK theo giấy phép GPL hiện đang được Oracle cung cấp chính thức, và các bản dựng từ nhiều nhà cung cấp khác cũng sẽ sớm được phát hành

Liên kết tải xuống OpenJDK chính thức

Các tính năng và cải tiến chính

Bản phát hành này bao gồm 18 JEP (Java Enhancement Proposal)

• 470: Mã hóa đối tượng mã hóa dựa trên PEM (xem trước)
• 502: Stable Values (xem trước)
• 503: Loại bỏ cổng x86 32-bit
• 505: Structured Concurrency (bản xem trước thứ 5)
• 506: Scoped Values
• 507: Hỗ trợ Primitive Types trong pattern, instanceof và switch (bản xem trước thứ 3)
• 508: Vector API (phiên bản incubator thứ 10)
• 509: Lập hồ sơ thời gian CPU của JFR (tính năng thử nghiệm)
• 510: Key Derivation Function API
• 511: Khai báo Module Import
• 512: Compact Source Files và phương thức main của instance
• 513: Flexible Constructor Bodies
• 514: Tối ưu hóa dòng lệnh Ahead-of-Time
• 515: Lập hồ sơ phương thức Ahead-of-Time
• 518: Lấy mẫu phối hợp JFR
• 519: Compact Object Headers
• 520: Định thời và theo dõi phương thức JFR
• 521: Generational Shenandoah

Ngoài các JEP ở trên, bản phát hành này còn bao gồm hàng trăm cải tiến tính năng nhỏ và hàng nghìn bản sửa lỗi

Thông tin phát hành chi tiết hơn và nội dung cụ thể của từng JEP có thể xem tại
Trang dự án OpenJDK JDK 25

[ahwjdekf]

Lại là màn đó từ năm ngoái, chưa chết mà lại mò tới, eo ôi hò dô ta vào cuộc.. Sao cứ là mày xuất hiện hoài vậy?

[click]

Đây là tính năng đã được đưa vào từ JDK 24, nhưng vì Java có xu hướng chủ yếu chỉ dùng các bản LTS nên điểm đáng chú ý là với JEP 491: Synchronize Virtual Threads without Pinning, hiện tượng pinning của virtual thread khi dùng từ khóa synchronized đã không còn nữa.
Trước đây benchmark virtual thread trong thực tế đôi khi chậm hơn, và trong đa số trường hợp nguyên nhân là do pinning.

[GN⁺]

Ý kiến trên Hacker News

• Tôi nghĩ nên có nhiều chương trình mới được viết bằng Java hoặc trên JVM hơn; hầu hết những lý do khiến Java mất độ phổ biến trong quá khứ giờ gần như không còn nữa, và hiện nay đây là một hệ sinh thái rất ổn định và trưởng thành. Một chương trình Clojure tôi viết từ 10 năm trước vẫn chạy tốt không vấn đề gì, trong khi chương trình viết bằng TypeScript thì chỉ sau 6 tháng đã cần bảo trì và cập nhật.
  • Điều khiến tôi lăn tăn lớn là Oracle; thật bất tiện khi dùng Java mà còn phải để ý để không vi phạm EULA của Oracle. Có lẽ dùng OpenJDK thì ổn, nhưng tôi vẫn muốn dùng ngôn ngữ khác để khỏi phải bận tâm. C# cũng cung cấp môi trường tương tự Java mà không phải lo chuyện Oracle. Thay vì học cách dùng Java cho an toàn, tôi nghĩ cứ chọn ngôn ngữ khác sẽ tốt hơn. Java cũng không phải là thứ bắt buộc, nên có rất nhiều lựa chọn thay thế.
  • Java vẫn cực kỳ phổ biến và được dùng rộng rãi trong các hệ thống backend quy mô lớn. Tôi khá ngạc nhiên vì ở đây có vẻ không nhiều người làm với kiểu hệ thống đó; theo kinh nghiệm của tôi thì gần như lúc nào cũng gặp Java.
  • Tôi đang âm thầm hy vọng Kotlin và Compose sẽ hồi sinh ứng dụng desktop trên JVM.
  • Tôi nghĩ điểm Java vẫn tiếp tục gặp rủi ro về mặt mức độ được chấp nhận là văn hóa xoay quanh nó. Các lập trình viên Java đời cũ và những chương trình Java hiện có thường được viết dài dòng không cần thiết, dù bản thân ngôn ngữ từ lâu đã có các tính năng cho phép viết ngắn gọn như những ngôn ngữ hiện đại khác. Dù vậy, Java là một thế lực quá lớn nên tôi nghĩ vẫn có khả năng thay đổi.
  • Tôi tò mò việc chương trình Clojure tôi viết 10 năm trước vẫn chạy tốt là nhờ JVM hay do đặc trưng riêng của Clojure. Tôi cũng có trải nghiệm tương tự với các dự án ClojureScript. Những script nbb cũ cũng chạy lại ngay gần như không vấn đề gì cả (thỉnh thoảng chỉ cần chỉnh chút ít dependency npm). Trong khi đó với Python, đôi lúc tôi phải vật lộn nửa ngày chỉ vì vấn đề dependency và quản lý venv.
• Java từ lâu đã là một nền tảng kỹ thuật đáng kinh ngạc về độ vững chắc. Có thể nó không phải ngôn ngữ hấp dẫn nhất, nhưng luôn cho thấy sự ổn định. Ứng dụng làm bằng Java 1.4 vẫn chạy tốt trên Java 21 LTS, và tôi đang định sớm nâng cấp lên Java 25. Java quá đỉnh.
  • Tôi tự hỏi Java giờ sẽ ở đâu nếu không có các công cụ xuất sắc của JetBrains và chương trình dành cho sinh viên rất thông minh của họ.
  • Dù chỉ là ký ức từ khá xa, tôi vẫn nhớ ứng dụng Gmail viết bằng Java chạy trên chiếc điện thoại Symbian cảm ứng của tôi hồi 2009. Nó thật sự dễ thương và dùng rất ổn.
  • Theo trải nghiệm của tôi thì tôi không thể hoàn toàn đồng ý. Mỗi lần nâng phiên bản JVM ở các công ty tôi từng làm đều luôn có vấn đề lớn và cần rất nhiều công sức làm lại, kiểm thử lại. Tôi dừng ở khoảng Java 17~18, nhưng những người làm cùng tôi hầu như không dùng các phiên bản mới. Năm 2022, ở một dự án tôi phải cập nhật JVM 1.5, nhưng các thư viện bên thứ ba quan trọng chỉ hỗ trợ tới trước Java 1.7 nên cực kỳ khó khăn. Tôi đã cố kiếm mã nguồn để tự biên dịch, nhưng phạm vi cứ ngày càng phình ra. Tôi cũng rất mệt mỏi vì bất đồng với quản lý, và cuối cùng quyết định rời khách hàng cấp cao nhất của một Fortune 10. Tôi nghe nói tới giờ hệ thống đó vẫn chưa được cập nhật.
  • Tôi từng muốn thử lại một ứng dụng Swing cũ mình viết, và có vẻ tôi có thể hồi sinh nó mà không cần sửa quá nhiều, nên tôi định thử.
  • JVM và hệ sinh thái của nó còn có thể dùng cùng các ngôn ngữ khác như Scala, Clojure, nên có nhiều cách tận dụng đa dạng và hấp dẫn.
• Thật ngạc nhiên là phải mất lâu đến vậy mới cho phép kiểm tra tính hợp lệ và chuyển đổi tham số trước khi gọi super trong constructor. Đây là điều tôi luôn thấy trái với trực giác từ rất lâu rồi.
  • Tôi dùng Java từ trước cả JDK 1.0, và chuyện này đã làm tôi khó chịu từ lâu, nhưng giờ thì tôi đã quen và quen cả với các cách lách.
  • Nếu bạn dùng hàm static để xử lý bước validate cho tham số của super, thì trên thực tế nó vẫn được gọi trước super, nên compiler cũng không phàn nàn gì.
• Tôi không phải lập trình viên Java, nhưng cá nhân tôi không thích hệ thống import module lắm. Cú pháp như import * giúp viết code dễ hơn, nhưng lại khiến việc đọc khó hơn nhiều, đặc biệt với những lập trình viên chưa quen ngôn ngữ hoặc codebase đó. C# và Nim cũng theo kiểu đó, và tôi thấy gần như không thể đọc nổi nếu không có IDE. Vì vậy tôi thích kiểu bí danh ngắn như của Python hơn (import torch.nn.functional as F).
  • Trong codebase lớn, vấn đề chính của import là “cái này từ đâu ra vậy?”. Import tường minh là rất cần thiết, nhất là khi build bị hỏng hoặc bị lẫn phiên bản dependency. Với codebase nhỏ thì sao cũng được. Dù sao editor bây giờ cũng hay ẩn dòng import, nên thực tế hiếm khi phải nhìn trực tiếp; tôi chỉ cần click vào code hoặc dùng phím tắt để nhảy tới định nghĩa, nên thường không quá để ý import.
  • Tôi nghĩ việc bạn có trải nghiệm không tốt với C# là vì bạn chưa dùng Visual Studio đúng nghĩa. VSCode cũng tốt, nhưng tôi sẽ không bao giờ mở file csproj hay sln bằng VSCode. Nhân tiện, Visual Studio có thể mua giấy phép vĩnh viễn giá $500 ở đây, và dùng mà không cần đăng ký thuê bao riêng.
  • Tôi không hiểu việc phàn nàn về cấu trúc ngôn ngữ khó hiểu nếu không có IDE. Đằng nào bạn cũng đang xem code trong IDE, nên tôi thấy chẳng thành vấn đề. Ai không dùng IDE thì tự làm mình bất tiện thôi, còn xem code trên GitHub thường cũng không phải để lần theo tham chiếu quá sâu, nên mức bất tiện đó để đổi lấy sự gọn gàng là chấp nhận được.
  • Theo tôi biết thì kiểu này được thiết kế để giúp việc viết chương trình chỉ có một file nguồn trở nên dễ hơn.
• Các tính năng mới được tổng hợp khá tốt trên trang chính thức của OpenJDK 25. Java 25 là bản phát hành LTS.
  • Tôi mong ngày phải làm migration từ 17 lên 25 trong 10 năm nữa sẽ sớm tới.
• Đây là cảm nhận cá nhân, nhưng Java là một ngôn ngữ cũ mà vẫn tiến hóa đều đặn suốt 10 năm qua, trong khi C++ thì ngược lại có vẻ còn khó hơn.
• Đáng tiếc là structured concurrency vẫn chưa được phát hành hoàn chỉnh. Tôi thực sự rất mong chờ tính năng này. Bù lại, việc bổ sung Scoped Values là điều đáng mừng; chỉ riêng vậy thôi cũng đủ để tôi thấy khi tổ chức code theo kiểu “rails-like” trong Java, không cần phải lạm dụng god-class hay god-object nữa.
  • So với tình cảnh khá hỗn loạn của C++ hiện nay, nơi có những tính năng đã được chuẩn hóa nhưng chưa có triển khai, tôi thấy cách Java đi dần từng bước qua preview là tốt hơn nhiều.
  • Tôi hy vọng structured concurrency sẽ là một bước tiến thực chất thay vì quá nặng tính “đường hóa” như async/await. Chỉ nhìn ví dụ thì tôi vẫn chưa bị thuyết phục, nhưng sẽ theo dõi thêm.
• Gần đây tôi quyết định rời JDK8 nên nhảy thẳng lên JDK21. Vì 25 đã cận kề nên tôi chọn 21 thay vì dừng ở 17. Theo tôi, lúc khó nhất là migration từ 8 lên 11 (do xuất hiện hệ thống module mới), còn sau đó thì khá dễ. Tôi làm Proof-of-Concept trên jdk17, và gần như giữ nguyên cũng chạy được trên jdk21 (chỉ có guice cần nâng major version). Nhân tiện, tôi nghĩ việc dùng ngôn ngữ JVM khác thay cho Java cũng đã giúp ích.
  • Đội của chúng tôi thấy việc chuyển từ 8 lên 17 khá vất vả. Chúng tôi dùng nhiều thứ không chính thức như gói sun, và việc chuyển từ javax sang jakarta cũng là một gánh nặng. Nhưng qua được chặng đó rồi thì lên 21 hay 25 lại thấy dễ. Tôi kỳ vọng việc bám theo các bản mới nhất từ nay sẽ dễ hơn trước.
  • Java 9 là khoảnh khắc Python 3 của hệ sinh thái, nhưng giờ tôi thấy mọi chuyện đã được dọn dẹp ổn thỏa rồi.
  • Tham khảo thêm, gần đây tôi đã migration từ 17 lên 21 mà không gặp vấn đề gì. Chỉ có vài chuyện nhỏ khi nâng Gradle cùng lúc (mà đó vốn là vấn đề khác).
• Các tính năng mới của Java 25 cũng được tổng hợp khá tốt trong bài viết của baeldung.
• Tôi tò mò hiện tại tình hình pháp lý khi dùng Java ra sao, cả cho mã nguồn mở lẫn mục đích thương mại. Oracle đang giữ những công nghệ tuyệt vời như Truffle gắn với Java, nên tôi muốn biết việc dùng nó cho dự án mới hợp lý đến mức nào.
  • OpenJDK về cơ bản là bản mã nguồn mở có giấy phép mở được lấy gần như trực tiếp từ Oracle. Nếu không thích Oracle thì có thể dùng các bản do Eclipse Foundation, Microsoft, Amazon và bên khác cung cấp. Sức sống của Java rất dài, đó cũng là lý do người ta vẫn dùng các bản cũ như 8/11. Chỉ cần viết xong là nó có thể chạy rất lâu. Về tính năng thì chậm hơn đối thủ, nhưng cho những phát triển quan trọng thì vẫn quá đủ. Nếu phụ thuộc vào JVM thì tôi khuyên dùng Kotlin (đặc biệt vì Java vẫn chưa có nullable type nên NullPointerException vẫn phổ biến). Nếu không thích Kotlin thì C# cũng tốt. Dù sao Java vẫn hoàn toàn dùng được.
  • Tính đến hiện tại, với bản phân phối của Oracle thì có thể hiểu là chỉ bản LTS mới nhất mới được dùng thoải mái. Các phiên bản thấp hơn theo giấy phép OTN nên chỉ dùng cho mục đích cá nhân/phát triển, không dùng cho production được. Nếu không nhất thiết cần nhãn Oracle thì OpenJDK hay JDK từ bên khác đều không có gì phải lo về giấy phép.
  • OpenJDK là mã nguồn mở hoàn toàn nên không cần lo lắng gì cả.
  • Nếu dùng thứ như OpenJDK thì hoàn toàn tránh được vấn đề Oracle.
  • Trừ khi bạn định tự làm rồi phân phối một bản triển khai Java riêng, còn không thì hầu như chẳng có vấn đề pháp lý nào đáng phải cân nhắc.