Java 25 / JDK 25 Resmi Dirilis

• Java 25 dan implementasi referensinya, JDK 25, telah resmi dirilis
• Versi ini mencakup 18 JEP (Java Enhancement Proposal) baru
• Perubahan utama mencakup penghapusan port x86 32-bit, Scoped Values, Structured Concurrency, dan peningkatan Primitive Types

---

Java 25 / JDK 25: Rilis Resmi

• JDK 25, yaitu implementasi referensi Java 25, telah resmi dirilis sebagai versi distribusi untuk penggunaan produksi
• Pada 15 Agustus 2025, release candidate kedua yaitu build 36 telah disediakan, dan sejak itu tidak ada laporan bug kritis (P1).
• build 36 menjadi versi GA (General Availability) final, dan dapat digunakan juga di lingkungan operasional

• Build OpenJDK berbasis lisensi GPL disediakan secara resmi oleh Oracle, dan versi build dari berbagai vendor lain juga akan segera didistribusikan

Link unduhan resmi OpenJDK

Fitur utama dan peningkatan

Rilis ini mencakup 18 JEP (Java Enhancement Proposal)

• 470: Encoding objek kriptografi berbasis PEM (pratinjau)
• 502: Stable Values (pratinjau)
• 503: Penghapusan port x86 32-bit
• 505: Structured Concurrency (pratinjau ke-5)
• 506: Scoped Values
• 507: Dukungan Primitive Types dalam pattern, instanceof, dan switch (pratinjau ke-3)
• 508: Vector API (versi inkubator ke-10)
• 509: Profiling waktu CPU JFR (fitur eksperimental)
• 510: Key Derivation Function API
• 511: Deklarasi Module Import
• 512: Compact Source Files dan metode main instans
• 513: Flexible Constructor Bodies
• 514: Optimisasi command-line Ahead-of-Time
• 515: Profiling metode Ahead-of-Time
• 518: Collaborative sampling JFR
• 519: Compact Object Headers
• 520: Timing dan tracing metode JFR
• 521: Generational Shenandoah

Selain JEP di atas, rilis ini juga mencakup ratusan peningkatan fitur kecil dan ribuan perbaikan bug

Informasi rilis lebih lanjut dan detail setiap JEP dapat dilihat di
Halaman proyek OpenJDK JDK 25

[ahwjdekf]

Pengemis keliling yang datang tahun lalu rupanya belum mati dan datang lagi, eolssigu sigu dimulai.. kenapa kamu terus muncul?

[click]

Ini memang fitur yang masuk di JDK 24, tetapi karena Java cenderung hanya memakai LTS, hal yang patut diperhatikan juga adalah bahwa dengan JEP 491: Synchronize Virtual Threads without Pinning, saat menggunakan kata kunci synchronized, fenomena pinning pada virtual thread sudah hilang.
Dalam benchmark virtual thread di dunia nyata, kadang performanya justru lebih lambat, dan dalam banyak kasus penyebab utamanya adalah pinning.

[GN⁺]

Opini Hacker News

• Saya rasa lebih banyak program baru seharusnya ditulis dengan Java atau di atas JVM; alasan menurunnya popularitas Java di masa lalu kini hampir sudah hilang, dan sekarang ekosistemnya sangat stabil dan matang. Bahkan program Clojure yang saya tulis 10 tahun lalu masih berjalan baik tanpa masalah, sedangkan program yang ditulis dengan TypeScript perlu pemeliharaan dan pembaruan hanya dalam 6 bulan.
  • Hal yang paling mengganggu adalah Oracle. Tidak nyaman harus selalu berhati-hati agar tidak melanggar EULA Oracle saat memakai Java. Mungkin aman jika menggunakan OpenJDK, tetapi saya lebih ingin memakai bahasa lain tanpa perlu khawatir. C# juga menyediakan lingkungan yang mirip Java tanpa kekhawatiran soal Oracle. Daripada mempelajari cara memakai Java dengan aman, saya merasa lebih baik langsung memilih bahasa lain. Java juga bukan sesuatu yang mutlak diperlukan, jadi pilihannya banyak.
  • Java masih sangat populer dan digunakan luas pada sistem backend berskala besar. Saya agak heran karena tampaknya tidak banyak orang di sini yang menangani sistem seperti itu. Dalam pengalaman saya, hampir tidak mungkin tidak bersentuhan dengan Java.
  • Saya diam-diam berharap Kotlin dan Compose bisa menghidupkan kembali aplikasi desktop di JVM.
  • Menurut saya, bagian yang masih berisiko bagi Java dari sisi tingkat adopsi adalah budaya di sekitarnya. Banyak pengembang Java lama dan program Java lama ditulis terlalu bertele-tele tanpa perlu, padahal bahasanya sendiri sudah punya fitur untuk ditulis ringkas seperti bahasa modern lain. Meski begitu, Java sangat besar sehingga saya rasa perubahan tetap mungkin terjadi.
  • Saya penasaran apakah program Clojure yang saya tulis 10 tahun lalu masih berjalan baik itu berkat JVM atau karena karakteristik khas Clojure. Saya juga punya pengalaman serupa di proyek ClojureScript. Skrip nbb lama pun langsung jalan tanpa banyak masalah, hanya sesekali perlu sedikit membenahi dependensi npm. Sebaliknya, di Python saya pernah menghabiskan setengah hari hanya untuk masalah dependensi dan pengelolaan venv.
• Java sudah lama menjadi fondasi teknis yang sangat kokoh. Memang bukan bahasa yang paling menarik, tetapi selalu menunjukkan kestabilan. Aplikasi yang dibuat dengan Java 1.4 masih berjalan baik di Java 21 LTS, dan saya berencana segera meng-upgrade ke Java 25. Java memang yang terbaik.
  • Saya penasaran Java sekarang akan berada di posisi mana kalau bukan karena tool buatan JetBrains yang luar biasa dan program mahasiswa mereka yang cerdas.
  • Meski saya menjaga jarak, saya masih ingat aplikasi Gmail berbasis Java yang berjalan di ponsel Symbian layar sentuh saya pada 2009. Aplikasinya benar-benar lucu dan fiturnya juga sangat berguna.
  • Dalam pengalaman saya, saya tidak bisa sepenuhnya setuju. Setiap kali menaikkan versi JVM di beberapa perusahaan, selalu ada masalah besar dan banyak pekerjaan ulang serta pengujian ulang yang diperlukan. Saya berhenti sekitar Java 17~18, tetapi orang-orang yang bekerja dengan saya hampir tidak pernah memakai versi baru. Pada 2022, di sebuah proyek saya harus memperbarui JVM 1.5, dan itu sangat sulit karena library pihak ketiga yang penting hanya mendukung versi sebelum Java 1.7. Saya mencoba mendapatkan source code-nya dan mengompilasinya sendiri, tetapi cakupannya makin meluas. Sulit juga karena tidak sejalan dengan para manajer, dan pada akhirnya saya memutuskan berhenti dari klien papan atas di Fortune 10. Katanya sampai sekarang sistem itu masih belum berhasil diperbarui.
  • Saya ingin mencoba lagi aplikasi Swing yang dulu pernah saya tulis, dan sepertinya bisa dihidupkan kembali tanpa banyak perubahan, jadi saya berniat mencobanya.
  • JVM dan ekosistemnya bisa dipakai bersama bahasa lain seperti Scala dan Clojure, jadi ada banyak penggunaan yang beragam dan menarik.
• Menarik juga bahwa butuh waktu selama ini sampai validasi dan konversi parameter sebelum pemanggilan super di konstruktor akhirnya diizinkan. Dulu saya selalu merasa bagian itu tidak intuitif.
  • Saya sudah memakai Java sejak sebelum JDK 1.0, dan bagian ini memang sudah lama terasa mengganggu, tetapi sekarang saya sudah terbiasa dan terbiasa juga dengan solusi memutarnya.
  • Jika selama ini Anda memakai fungsi static untuk proses validasi pada parameter super, secara praktik itu memang dipanggil sebelum super, jadi compiler juga tidak mempermasalahkannya.
• Saya bukan pengembang Java, tetapi secara pribadi saya kurang suka sistem import modulnya. Sintaks seperti import * memang memudahkan saat menulis kode, tetapi jauh lebih sulit dibaca, terutama bagi pengembang yang belum familier dengan bahasa atau codebase tersebut. C# dan Nim juga punya gaya seperti itu, dan tanpa IDE saya hampir tidak bisa membacanya. Karena itu saya lebih suka contoh alias singkat seperti di Python (import torch.nn.functional as F).
  • Dalam codebase besar, masalah utama import adalah, "Ini datang dari mana?" Import yang eksplisit memang perlu. Ini terutama terasa saat build rusak atau versi dependensi membingungkan. Di codebase kecil sih apa pun tidak masalah. Lagi pula editor sekarang biasanya menyembunyikan baris import, jadi kita hampir tidak pernah melihatnya langsung, dan karena tinggal klik kode atau pakai shortcut untuk langsung melompat, saya juga biasanya tidak terlalu memikirkan import.
  • Menurut saya pengalaman buruk dengan C# itu karena tidak memakai Visual Studio yang benar. VSCode memang bagus, tetapi saya tidak akan pernah membuka file csproj atau sln di VSCode. Sebagai referensi, Visual Studio bisa dibeli dengan lisensi perpetual seharga $500 di sini, dan bisa dipakai tanpa langganan terpisah.
  • Saya tidak begitu paham mengapa orang mengeluh soal konstruksi bahasa yang sulit dipahami tanpa IDE. Toh kita melihat kode di IDE, jadi menurut saya tidak masalah. Orang yang tidak memakai IDE berarti menciptakan ketidaknyamanan untuk dirinya sendiri, dan melihat kode di GitHub biasanya bukan untuk menganalisis referensi secara mendalam, jadi ketidaknyamanan demi keringkasan itu masih bisa diterima.
  • Setahu saya, gaya ini memang dimaksudkan agar lebih mudah menulis program dalam satu source file.
• Fitur-fitur baru dirangkum dengan baik di halaman resmi OpenJDK 25. Java 25 adalah rilis LTS.
  • Semoga hari ketika saya harus mengerjakan migrasi dari 17 ke 25 sepuluh tahun dari sekarang cepat datang.
• Ini kesan pribadi saya, tetapi meskipun Java adalah bahasa lama, dalam 10 tahun terakhir Java terus berkembang secara konsisten, sementara C++ justru terasa makin sulit.
• Sayangnya, structured concurrency masih belum dirilis sepenuhnya. Saya sangat menantikan fitur ini. Sebagai gantinya, saya senang dengan penambahan Scoped Values. Hanya dengan ini saja saya merasa di Java kita bisa menyusun kode dengan gaya "rails-like" tanpa harus berlebihan memakai god-class atau god-object.
  • Dibanding situasi C++ yang membingungkan karena fitur-fitur yang sudah distandardisasi tetapi belum ada implementasinya, saya rasa pendekatan Java saat ini yang bergerak bertahap lewat preview jauh lebih baik.
  • Saya berharap structured concurrency terasa sebagai kemajuan yang nyata, bukan sekadar terlalu banyak gula sintaks seperti async/await. Dari contoh-contoh yang saya lihat saya masih belum yakin, tetapi saya akan terus memperhatikannya.
• Baru-baru ini saya memutuskan migrasi dari JDK8 dan langsung lompat ke JDK21. Karena 25 sudah di depan mata, saya memilih 21 alih-alih berhenti di 17. Menurut saya, migrasi dari 8 ke 11 adalah yang paling sulit karena muncul sistem modul baru, dan setelah itu semuanya terasa mudah. Proof-of-Concept saya dibuat di jdk17 dan hampir apa adanya berjalan juga di jdk21, hanya guice yang perlu upgrade major version. Sebagai catatan, memakai bahasa JVM lain alih-alih Java juga tampaknya membantu.
  • Tim kami merasa perpindahan dari 8 ke 17 cukup sulit. Kami banyak memakai hal-hal yang tidak resmi seperti paket sun, dan perpindahan dari javax ke jakarta juga menjadi beban. Setelah melewati tahap itu, pindah ke 21 atau 25 terasa mudah. Saya berharap ke depannya akan lebih mudah untuk terus mengikuti versi terbaru secara rutin dibanding dulu.
  • Java 9 adalah momen Python 3 bagi ekosistem ini, tetapi sekarang rasanya semuanya sudah rapi tanpa masalah.
  • Sebagai referensi, saya baru-baru ini migrasi dari 17 ke 21 dan tidak mengalami masalah sama sekali. Ada isu kecil saat menaikkan Gradle bersamaan, tetapi itu pada dasarnya masalah lain.
• Fitur-fitur baru Java 25 juga dirangkum dengan baik dalam postingan baeldung.
• Dari sudut pandang hukum, saya penasaran bagaimana situasi memakai Java saat ini, baik untuk open source maupun penggunaan komersial. Oracle menahan teknologi hebat seperti Truffle tetap terikat pada Java, jadi saya ingin tahu seberapa masuk akal memakainya untuk proyek baru.
  • OpenJDK pada dasarnya adalah versi berlisensi terbuka yang langsung berasal dari Oracle. Jika tidak suka Oracle, Anda bisa memakai versi buatan pihak lain seperti Eclipse Foundation, Microsoft, atau Amazon. Daya tahan Java memang panjang, dan itu juga alasan mengapa versi lama seperti 8/11 masih dipakai. Sekali ditulis, programnya benar-benar bisa berjalan sangat lama. Dari sisi fitur memang lebih lambat dibanding pesaing, tetapi untuk pengembangan penting sudah cukup. Jika Anda bergantung pada JVM, saya merekomendasikan Kotlin, terutama karena Java masih belum punya nullable type sehingga NullPointerException masih umum. Jika tidak suka Kotlin, C# juga bagus. Meski begitu, Java tetap sangat layak dipakai.
  • Untuk saat ini, pada distribusi Oracle praktis hanya LTS terbaru yang bisa dipakai bebas. Versi di bawah itu memakai lisensi OTN, jadi hanya boleh untuk penggunaan pribadi/pengembangan dan tidak untuk production. Jika Anda tidak butuh tanda Oracle, OpenJDK atau JDK dari vendor lain tidak menimbulkan kekhawatiran lisensi.
  • OpenJDK sepenuhnya open source, jadi tidak perlu khawatir sama sekali.
  • Jika memakai sesuatu seperti OpenJDK, Anda sepenuhnya bebas dari isu Oracle.
  • Kecuali Anda ingin membuat dan mendistribusikan implementasi Java sendiri, isu hukum hampir tidak pernah benar-benar menjadi pertimbangan.