Java 27 Resmi Dirilis: Apa Saja yang Baru?

Java 27 (JDK 27) resmi mencapai tahap general availability pada 15 September 2026, sekitar enam bulan setelah Java 26. Rilis ini membawa sembilan JDK Enhancement Proposal (JEP) yang sebagian besar menyentuh lapisan yang jarang terlihat tetapi paling berpengaruh pada aplikasi produksi: kriptografi TLS, garbage collection, ukuran object di dalam heap, concurrency, hingga API kriptografi.

Java 27 adalah rilis fitur (non-LTS), bukan rilis dukungan jangka panjang. Versi LTS terbaru tetap Java 25, jadi keputusan yang paling penting bagi tim produksi bukan “apakah fitur barunya menarik”, melainkan “apakah versi ini perlu dipasang sekarang”.

Artikel ini merangkum apa yang baru di Java 27, mana yang sudah final dan mana yang masih berstatus preview, serta hal yang layak diperiksa sebelum menaikkan versi di proyek yang sedang berjalan. Catatan tentang rilis lain yang kami nilai berdampak ada di topik Berita & Rilis.

Java 27 dalam poin singkat

• Apa itu: rilis fitur JDK ke-27, hasil kerja proyek OpenJDK, dengan Java SE 27 sebagai spesifikasi resminya.
• Tanggal rilis: 15 September 2026 (general availability).
• Status: non-LTS. Rilis dukungan jangka panjang terbaru adalah Java 25.
• Isi: sembilan JEP — empat sudah final, empat masih preview, satu masih incubator.
• Yang paling cepat terasa: G1 sebagai garbage collector default di semua environment dan compact object headers; keduanya bekerja tanpa mengubah kode aplikasi.
• Jendela pembaruan Oracle JDK 27: sampai sekitar Maret 2027, sebelum siklus dilanjutkan JDK 28.

Sembilan JEP di Java 27

Java 27 tidak sekadar menambah sintaks baru. Daftar berikut memperlihatkan di mana perubahan sesungguhnya terjadi — dan mana yang belum boleh diandalkan untuk produksi.

JEP	Judul	Status	Dampak utama
523	Make G1 the Default Garbage Collector in All Environments	Selesai	perilaku memori lebih konsisten
527	Post-Quantum Hybrid Key Exchange for TLS 1.3	Selesai	kesiapan keamanan jangka panjang
531	Lazy Constants (Third Preview)	Preview	inisialisasi nilai saat dibutuhkan
532	Primitive Types in Patterns, instanceof, and switch (Fifth Preview)	Preview	pattern matching lebih konsisten
533	Structured Concurrency (Seventh Preview)	Preview	pengelolaan pekerjaan paralel
534	Compact Object Headers by Default	Selesai	heap lebih hemat
536	JFR In-Process Data Redaction	Selesai	data sensitif tidak ikut terekam
537	Vector API (Twelfth Incubator)	Incubator	komputasi SIMD
538	PEM Encodings of Cryptographic Objects (Third Preview)	Preview	encoding objek kriptografi

Statusnya penting: fitur preview masih bisa berubah di rilis berikutnya dan memerlukan flag --enable-preview saat kompilasi maupun saat dijalankan, sedangkan modul incubator perlu ditambahkan secara eksplisit. Keduanya bukan bahan untuk kode produksi.

Post-quantum hybrid key exchange untuk TLS 1.3

Perubahan keamanan paling signifikan pada Java 27 datang lewat JEP 527. TLS 1.3 kini dapat menegosiasikan hybrid key exchange: skema yang menggabungkan pertukaran kunci klasik dengan algoritma yang dirancang tahan terhadap ancaman komputer kuantum — misalnya kombinasi X25519 dengan ML-KEM.

Yang membuatnya menarik secara praktis: aplikasi yang memakai API javax.net.ssl — mulai dari HttpsURLConnection sampai HttpClient — bisa memperoleh mekanisme baru ini tanpa perubahan besar di kode aplikasi. Seperti pembaruan keamanan lain di platform, manfaatnya datang dari versi JDK yang dipakai, bukan dari penulisan ulang koneksi.

Bagi pemilik layanan publik, ini bukan urusan yang mendesak hari itu juga, tetapi masuk kategori yang layak dicatat: koneksi TLS yang terekam hari ini bisa didekripsi di kemudian hari bila algoritma kuncinya kelak dianggap lemah.

G1 menjadi garbage collector default di semua environment

JEP 523 mengubah perilaku default yang selama ini berbeda antar-lingkungan. Sebelumnya, pada kondisi tertentu — misalnya arsitektur 32-bit atau lingkungan dengan sumber daya terbatas — HotSpot JVM masih bisa memilih Serial Garbage Collector sebagai default. Mulai Java 27, JVM yang tidak diberi opsi eksplisit selalu memakai G1.

Manfaatnya bukan kecepatan sesaat, melainkan perilaku yang konsisten: laptop pengembang, container di CI, dan server produksi menjalankan strategi pengelolaan memori yang sama, sehingga hasil pengukuran lebih mudah dibandingkan.

Konsekuensinya juga perlu disadari: beban kerja kecil yang dulu memakai Serial GC akan merasakan perubahan perilaku. Untuk memeriksa apa yang benar-benar dipakai JVM:

java -XX:+PrintFlagsFinal -version | grep UseG1GC

Nilai bool UseG1GC = true berarti G1 dipakai. Bila sebuah beban kerja ternyata lebih baik dengan collector lain, pilihan itu tetap tersedia secara eksplisit (-XX:+UseSerialGC, -XX:+UseZGC, -XX:+UseParallelGC), dan pengukuran adalah cara memutuskan.

Compact object headers menjadi default

Perubahan kedua yang langsung menyentuh penggunaan memori datang dari JEP 534. Pada arsitektur 64-bit, Compact Object Headers sekarang menjadi konfigurasi default: ukuran header setiap object dipangkas dari 96 bit menjadi 64 bit.

Efeknya terasa pada aplikasi dengan jumlah object yang besar:

• heap lebih hemat — jumlah memori yang sama bisa menampung lebih banyak object;
• data locality lebih baik — object yang relevan lebih sering berada di cache line yang sama;
• tekanan pada garbage collector berkurang, karena ruang yang harus dipindai lebih kecil.

Untuk aplikasi yang memuat jutaan object kecil — pemrosesan data, layanan dengan banyak sesi, hingga service yang menyimpan banyak nilai pendek — penghematan ini biasanya terlihat langsung pada penggunaan memori, tanpa perubahan kode. Catatan pentingnya tetap ada: perilaku memori berubah, jadi ukur ulang pada beban kerja nyata. Bila muncul masalah spesifik, opsi -XX:-UseCompactObjectHeaders masih tersedia untuk kembali ke perilaku lama.

Structured concurrency

JEP 533 membawa Structured Concurrency ke preview ketujuh. Konsepnya sederhana: sekumpulan pekerjaan yang saling berkaitan diperlakukan sebagai satu unit.

Task
├── Subtask A
├── Subtask B
└── Subtask C

Ketika ketiga subtask berada dalam satu scope, pembatalan, penanganan galat, dan siklus hidup thread-nya menjadi lebih terstruktur: kalau satu subtask gagal atau dibatalkan, subtask lain ikut ditangani, dan tidak ada pekerjaan yang berjalan tanpa pemilik.

Pola ini paling relevan untuk aplikasi server dan microservices yang memanggil beberapa layanan sekaligus — bukan untuk menambah jumlah thread, melainkan untuk membuat perilaku saat gagal bisa diprediksi. Karena masih preview, API-nya belum boleh dianggap stabil di antara rilis.

Primitive types dalam pattern matching

JEP 532 melanjutkan pengembangan pattern matching dengan membawa dukungan tipe primitif ke konstruksi instanceof dan switch. Tujuannya membuat pola berpikir yang sudah dipakai untuk object berlaku juga untuk nilai primitif, sehingga kode pemetaan dan validasi tidak perlu bercabang antara dua gaya penulisan.

Fitur ini sudah melewati preview kelima, artinya arah desainnya cukup matang namun detail API-nya masih bisa berubah. Di Java 27 statusnya tetap preview.

Lazy constants

JEP 531 melanjutkan Lazy Constants ke preview ketiga. Idenya: sebuah nilai baru dibuat ketika benar-benar dibutuhkan, bukan saat kelas dimuat.

Aplikasi dimulai
      ↓
Konstanta belum digunakan
      ↓
Tidak perlu diinisialisasi
      ↓
Konstanta pertama kali diakses
      ↓
Nilai dibuat sekali, lalu dipakai ulang

Lazy constant berguna ketika proses pembuatan sebuah nilai cukup mahal — membaca konfigurasi, membangun koneksi, menyiapkan data referensi — atau ketika logika inisialisasinya perlu tetap bebas dari masalah urutan dan race condition. Fitur ini sebelumnya dikenal sebagai Stable Values dan berganti nama seiring pengembangannya.

JFR in-process data redaction

Java Flight Recorder (JFR) adalah cara paling praktis untuk menelusuri masalah di produksi — tetapi berkas recording-nya bisa memuat hal yang seharusnya tidak pernah tersimpan. JEP 536 menambahkan redaction di dalam proses JVM, sebelum data masuk ke recording.

Sumber data yang rutin memuat informasi sensitif:

Command-line arguments
Environment variables
System properties

Ketiganya sering mengandung password, token, API key, atau alamat layanan internal. Dengan redaction yang terjadi di dalam proses JVM, kemungkinan data tersebut ikut tersimpan dalam berkas diagnostik berkurang — hal yang penting ketika berkas rekaman dibagikan ke pihak ketiga atau dilampirkan ke tiket dukungan.

Vector API

JEP 537 membawa Vector API ke incubator kedua belas. API ini memungkinkan operasi komputasi vektor ditulis secara eksplisit, lalu diterjemahkan JVM menjadi instruksi SIMD pada CPU yang mendukungnya, sehingga beberapa nilai bisa diproses dalam satu instruksi.

Beban kerja yang biasanya memperoleh manfaat:

• pemrosesan data dan analitik
• komputasi ilmiah dan numerik
• pembelajaran mesin serta inferensi AI
• pemrosesan citra dan sinyal

Statusnya masih incubator, sehingga modulnya harus ditambahkan secara eksplisit (--add-modules jdk.incubator.vector) dan API-nya belum berstatus final.

PEM encodings of cryptographic objects

JEP 538 melanjutkan API untuk PEM Encodings of Cryptographic Objects ke preview ketiga. PEM adalah format teks yang paling sering dijumpai ketika berhadapan dengan objek kriptografi:

Private key
Public key
Certificate
Certificate revocation list

Pekerjaan ini sebelumnya biasanya dibantu library pihak ketiga. API baru ini menyediakan jalur standar di dalam platform untuk encoding dan decoding format tersebut, sehingga kode keamanan tidak perlu bergantung pada dependensi tambahan untuk tugas yang cukup sederhana. Statusnya masih preview.

Java 27 dan pengembangan aplikasi modern

Dilihat sebagai satu kesatuan, Java 27 bukan rilis “fitur baru untuk dicoba”, melainkan rilis yang merapikan fundamental:

• kriptografi dan keamanan koneksi
• garbage collection dan penggunaan memori
• concurrency serta pengelolaan pekerjaan paralel
• performa komputasi
• observability dan kebersihan data diagnostik
• developer experience

Arah ini menjelaskan untuk siapa Java modern dikembangkan: aplikasi server, layanan cloud-native dan microservices, pemrosesan data, serta beban kerja AI. Hampir semua peningkatan di Java 27 terasa paling besar pada layanan yang berjalan lama dan memegang banyak sesi sekaligus.

Apakah perlu upgrade ke Java 27?

Jawabannya bergantung pada jenis sistem yang Anda jalankan, bukan pada seberapa menarik daftar fiturnya.

Java 27 cocok dipasang bila:

• Anda sedang mengembangkan atau mempelajari fitur Java terbaru dan ingin merasakan perubahan default terbaru lebih dulu;
• Anda ingin menguji kesiapan aplikasi sebelum rilis LTS berikutnya;
• Anda punya beban kerja yang berpotensi memperoleh manfaat dari header object yang lebih kecil atau negosiasi TLS hybrid.

Java 27 bukan pilihan pertama bila:

• layanan Anda berjalan di produksi dan membutuhkan jendela dukungan yang panjang — Java 25 LTS masih pilihan yang lebih tepat;
• Anda bergantung pada API preview: perilakunya masih bisa berubah antar rilis;
• tim Anda belum punya jalur uji dan rollback untuk perubahan versi runtime.

Sebelum menaikkan versi di produksi, periksa kompatibilitas seluruh rantai yang dimiliki aplikasi:

Framework
Library
Build tool
Application server
Database driver
Monitoring agent
CI/CD pipeline
Container image

Terutama bila aplikasi masih berjalan di versi yang jauh lebih lama: melompat dari Java 8, 11, atau 17 biasanya bukan soal JDK-nya, melainkan soal dependensi yang belum siap.

Cara memeriksa versi Java

Setelah JDK 27 terpasang, cara tercepat memastikan versi yang aktif adalah:

java --version
javac --version

Perintah pertama menampilkan runtime yang dipakai, perintah kedua menampilkan compiler. Keduanya penting karena pada mesin dengan beberapa JDK, java dan javac bisa menunjuk ke instalasi yang berbeda — situasi yang sering menjadi penyebab “kok sintaksnya tidak dikenali”.

Pertanyaan yang sering muncul

Apakah Java 27 versi LTS?

Tidak. Java 27 adalah feature release non-LTS. Rilis dukungan jangka panjang terbaru adalah Java 25, dan rilis LTS berikutnya mengikuti pola dua tahun yang sudah dijalankan Oracle.

Berapa lama Oracle JDK 27 didukung?

Oracle menjadwalkan pembaruan untuk Oracle JDK 27 sampai sekitar Maret 2027, lalu siklusnya dilanjutkan JDK 28. Artinya Java 27 adalah versi untuk diuji dan dipelajari, bukan versi yang dipasang lalu dilupakan.

Apa saja fitur baru di Java 27?

Sembilan JEP: G1 sebagai GC default, post-quantum hybrid key exchange untuk TLS 1.3, compact object headers sebagai default, JFR in-process data redaction, empat fitur preview (lazy constants, primitive types dalam pattern matching, structured concurrency, PEM encodings), dan satu incubator (Vector API).

Apakah G1 sekarang selalu dipakai?

Hampir selalu: sejak Java 27 JVM memakai G1 secara default di semua environment, kecuali Anda menentukan collector lain secara eksplisit.

Apakah Compact Object Headers bisa dimatikan?

Bisa, lewat opsi -XX:-UseCompactObjectHeaders. Menonaktifkannya mengembalikan susunan header object seperti rilis sebelumnya, dan keputusan itu sebaiknya diambil berdasarkan pengukuran.

Apakah fitur preview boleh dipakai di produksi?

Secara teknis bisa, secara praktik tidak disarankan. Fitur preview bisa berubah atau dihapus di rilis berikutnya, dan kodenya memerlukan --enable-preview yang terikat pada satu versi JDK tertentu.

Apakah aman naik langsung dari Java 21 ke Java 27?

Untuk banyak aplikasi, ya — tetapi yang perlu diperiksa bukan hanya JDK-nya. Periksa dependensi, driver basis data, agen monitoring, plugin build, dan image container. Bila memungkinkan, uji di lingkungan yang mirip produksi dan siapkan langkah rollback sebelum memutuskan.

Di mana JDK 27 bisa diunduh?

Dari Oracle, atau sebagai distribusi OpenJDK dari vendor build seperti Eclipse Temurin, Amazon Corretto, Azul, dan Microsoft Build of OpenJDK. Pilih build yang jendela dukungannya sesuai kebutuhan Anda, bukan sekadar yang paling cepat terpasang.

Kesimpulan

Java 27 melanjutkan evolusi Java dengan fokus yang cukup jelas pada hal yang menentukan biaya jangka panjang: keamanan koneksi, efisiensi memori, perilaku default yang konsisten, dan pemrosesan paralel yang lebih mudah diprediksi.

Poin utama rilis ini:

• post-quantum hybrid key exchange untuk TLS 1.3 (JEP 527)
• G1 sebagai garbage collector default di semua environment (JEP 523)
• compact object headers sebagai default (JEP 534)
• in-process data redaction untuk JFR (JEP 536)
• structured concurrency, primitive types dalam pattern matching, lazy constants, dan PEM encodings yang masih preview
• vector API yang masih incubator

Karena bukan versi LTS, Java 27 paling masuk akal dipakai sebagai ruang uji: mengukur kompatibilitas framework dan library, mengenali perubahan default lebih awal, dan menyiapkan jalur naik versi yang tenang ketika rilis LTS berikutnya tiba. Untuk sistem produksi yang membutuhkan dukungan panjang, Java 25 LTS tetap menjadi acuan — sementara Java 27 adalah tempat belajar yang aman.

Menjalankan beban kerja Java di produksi dan sedang menimbang naik versi? Kirim gambaran singkat tentang lingkungan Anda dan kami bantu menyusun urutan uji serta langkah rollback yang paling kecil risikonya. Bacaan terkait: standar kode kami, panduan praktis yang kami rawat, dan kebiasaan ops yang menjaga versi tetap terkendali.

Referensi

Sumber yang kami rujuk saat menyusun artikel ini:

• OpenJDK — JDK 27
• Oracle Java Blog — The Arrival of Java 27
• OpenJDK — JEP Index
• Oracle — Java SE Documentation